Custom kernel and extension dependencies

[helander]

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

[Jason W]

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.
  

[helander]

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.

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

[curaga]

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.

[mavrothal]

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.

[danielibarnes]

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.

[helander]

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

[hiro]

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?

[curaga]

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.

[hiro]

The .info confuses me:

This extension contains:
- 2.6.32.7 kernel headers (GPL)

[curaga]

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.

[curaga]

We have decided the procedure for custom kernels, see the sticky:

http://forum.tinycorelinux.net/index.php?topic=8923.0