WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Custom kernel and extension dependencies  (Read 5716 times)

Offline helander

  • Full Member
  • ***
  • Posts: 183
Custom kernel and extension dependencies
« on: January 07, 2010, 01:56:47 PM »
It is very easy to use custom kernels together with TC/MC. The only thing right now that causes a problem for me is that some of the extensions in the repository have dependencies (.dep file) that explicitly refer to kernel module extensions for the current TC/MC kernel.

I propose that the extension loading tools (appbrowser, tce-load, ...) becomes "kernel version aware" in the following way:

When they are to operate on a file that has "2.6.29.1-tinycore" in its name, they will substitute that string with the string given by executing "uname -r".

In version 3 (when the .dep files have to be rewritten to adjust to the new standard kernel) the name in the dep files could be modified to something like "xxxx-$KERNEL.tcz" and that the loading tools then substitute $KERNEL with the result from "uname -r".

This would allow TC/MC to officially being able to support multiple kernel alternatives in the standard repos and make life easier for us that for some reason uses custom kernels.

Kind Regards

Lars

Offline Jason W

  • Retired Admins
  • Hero Member
  • *****
  • Posts: 9730
Re: Custom kernel and extension dependencies
« Reply #1 on: January 07, 2010, 04:11:38 PM »
If a `uname -r` was used as a variable in a dep file, then those who make custom kernels would have to make module extensions that correspond to what is available in the repo.  It wouldn't allow the choice of just leaving your custom kernel modules in your initrd, or as one large extension which I imagine the majority of those with custom kernels use one of these two approaches.  

I can't think of a way to not have module extensions load when another kernel is being used aside from removing module extensions from dep files and instead mentioning the dependency in the info file.  Though that would help those with custom kernels, it would be punishing the majority of users.  There are about 32 dep files that contain kernel module extensions, and though that is not a lot, it would affect the experience of using TC to not have module extension dependencies resolved as is present.
  


« Last Edit: January 07, 2010, 04:14:27 PM by Jason W »

Offline helander

  • Full Member
  • ***
  • Posts: 183
Re: Custom kernel and extension dependencies
« Reply #2 on: January 07, 2010, 05:37:28 PM »
Quote
If a `uname -r` was used as a variable in a dep file, then those who make custom kernels would have to make module extensions that correspond to what is available in the repo.  It wouldn't allow the choice of just leaving your custom kernel modules in your initrd, or as one large extension which I imagine the majority of those with custom kernels use one of these two approaches.  
I think you are correct in that users of custom kernels do not package the modules according to the same structure as has been done by the modules for the standard kernel, but I would gladly package according to that structure in case that allowed me to automatically gain the benefit of the dependency information.

Quote
I can't think of a way to not have module extensions load when another kernel is being used aside from removing module extensions from dep files and instead mentioning the dependency in the info file.  Though that would help those with custom kernels, it would be punishing the majority of users.  There are about 32 dep files that contain kernel module extensions, and though that is not a lot, it would affect the experience of using TC to not have module extension dependencies resolved as is present.

If the loading tools looked for the string "2.6.29.1-tinycore" in the names of packages when loading and just discarded to load such packages if `uname -r` returned something else, then that would help users of custom kernels and others would be unaffected.

/Lars

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: Custom kernel and extension dependencies
« Reply #3 on: January 08, 2010, 04:31:09 PM »
Makes sense. I wouldn't consider it for 2.x though.

The issue Jason refers to is the fact that tce-load currently exits if a dep doesn't exist.
If in 3.x it would instead just skip it, while still of course printing an error and exiting with an error code, having a variable would not cause issues to those having modules in a differing form from the repo.

Also, I'll likely post the sorting script for the 3.x series, so that should help with creating the extensions.


On the other side, do you mean to post the extensions to the standard repo? I see the issue that having them there would cause confusion, and expectation that we offer officially all the kernels for which there are extensions.
The only barriers that can stop you are the ones you create yourself.

Offline mavrothal

  • Newbie
  • *
  • Posts: 43
Re: Custom kernel and extension dependencies
« Reply #4 on: February 06, 2010, 08:44:12 AM »
I'm developing a TC version for the olpc XO-1 computer that requires a custom kernel, and I'm really stuck with kernel-specific extensions for major components like sound or power management.
I'm sure you have thought of it, but waht about if .tcz could be downloaded from the browser and the deps etc could be modified by the user to kernel specs. Some explicit warnings could appear or even use a distinct web page to avoid TC user confusion.
Disclamer: i just stumble upon tiny core a week ago, so if I miss something obvious to everybody else (eg "but there is such a site" ::)), apologies.

Offline danielibarnes

  • Hero Member
  • *****
  • Posts: 548
Re: Custom kernel and extension dependencies
« Reply #5 on: February 08, 2010, 07:17:29 PM »
I've thought about the feasibility of upgrading the kernel too. If a long-term support kernel like 2.6.32 were chosen for 3.0 (although personally I am hoping for 2.6.33 because vmware drivers are included), then it would be a nice-to-have if the kernel+modules (at least the core.gz modules) could be easily upgraded to the latest minor release.

For my own purposes, I'd split tinycore.gz into tinycore.gz + modules-2-6-29-1.gz then specify isolinux to load them together so I could build new modules and swap them out. Then if I had any extensions with modules, I'd just rebuild them for the new kernel.

It might be worth adding a "build" column to the repository alongside info, list, md5, and dep to show the build script used by the submitter to build the extension.

Offline helander

  • Full Member
  • ***
  • Posts: 183
Re: Custom kernel and extension dependencies
« Reply #6 on: February 08, 2010, 08:07:41 PM »

Quote
For my own purposes, I'd split tinycore.gz into tinycore.gz + modules-2-6-29-1.gz then specify isolinux to load them together so I could build new modules and swap them out. Then if I had any extensions with modules, I'd just rebuild them for the new kernel.

This is close to how I do today. I create a modules-mykernel.gz that contains the same set of modules that are found in tinycore.gz. This means that I get two sets of modules  in memory of which only one set gets used. Having the modules separated out of tinycore.gz (and microcore.gz) and let the boot loader do the merge would be great in my view. For people relying on boot loaders that can not do this, there is always the option to create a remastered tinycore.gz that has the modules included. It's easier to combine than split :)

In other distributions you typically have no dependency information between packages and kernel modules at all or you do management of dependencies and modules of arbitrary kernel versions. TC/MC today is sort of in between and works good if you are mainstream but has flaws if you are not. I think most of this can be "solved" with fairly easy measures, but I do realize that we "custom kernel nerds" might have to live with the situation as is. However I am willing to contribute with the changes required to make the system work "properly" with modules for custom kernels.

/Lars

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: Custom kernel and extension dependencies
« Reply #7 on: March 05, 2011, 01:21:46 PM »
How do the amd64 module extensions currently get built? Is the kernel compiled two times? How about the sorter.sh script?

Can module creators currently create amd64 extensions easily?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: Custom kernel and extension dependencies
« Reply #8 on: March 05, 2011, 01:34:33 PM »
Using the toolchain64 cross-compiler. It's a separate build from the 32-bit one, and a separate run with sorter.sh.

In comparison to a normal kernel build, it requires exporting a couple variables to let it cross-compile and find the right gcc. I have posted those before, as has Arslan, IIRC.
The only barriers that can stop you are the ones you create yourself.

Offline hiro

  • Hero Member
  • *****
  • Posts: 1229
Re: Custom kernel and extension dependencies
« Reply #9 on: March 05, 2011, 01:45:49 PM »
The .info confuses me:
Quote
This extension contains:
- 2.6.32.7 kernel headers (GPL)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: Custom kernel and extension dependencies
« Reply #10 on: March 05, 2011, 01:53:31 PM »
The kernel headers are locked into place when glibc is built, they rarely match what is running. They don't affect compatibility in any way, one can still run that glibc on earlier and later kernels.
The only barriers that can stop you are the ones you create yourself.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: Custom kernel and extension dependencies
« Reply #11 on: March 07, 2011, 02:37:46 PM »
We have decided the procedure for custom kernels, see the sticky:

http://forum.tinycorelinux.net/index.php?topic=8923.0
The only barriers that can stop you are the ones you create yourself.