View Single Post
Posts: 540 | Thanked: 288 times | Joined on Sep 2009
#58
I ran into titan on IRC and after some discussion about idea he asked me to continue here. everything IMO YMMV etc HAND.

Name

IMO "kernel-community" is better than "kernel-maemo" in indicating that this is indeed not the official maemo kernel and thus will be using that name in the following examples.

Packaging ideas

Use Provides liberally to denote features, this way applications can depend on the features and not specific kernel/module package.

First simple example, joydev.ko:

There could be package "kernel-modules-joydev" that is compiled against otherwise fully stock kernel since (unlike NAT) this module does not need any special symbols in the kernel proper. "kernel-modules-joydev" provides only one file 'joydev.ko' which is placed in the modules directory of the stock kernel. "kernel-modules-joydev" depends on the exact binary version of the stock kernel it was compiled against.

Now there's another package "kernel-community-modules-joydev", same idea as above but compiled against the "kernel-community" "stock" configuration, depends on the exact version of "kernel-community" etc. HOWEVER: it adds "Provides: kernel-modules-joydev" to the control file.

This way application depending on joydev can work with either kernel.

The joydev is example of a single module, but there could be plenty more Provides features like "kernel-modules-nat" and "kernel-modules-qos" both of which require extra features from the kernel itself so they're either provided by the "kernel-community-modules" package or as separate "kernel-community-modules-nat" and "kernel-community-modules-qos" packages.

Again an application should depend on the generic "kernel-modules-nat" feature and thus if there are many kernels providing it any one of them is usable, no need to switch from custom kernel X to custom kernel Y just because some app has stupid depends line.

I take this approach in http://mobilehotspot.garage.maemo.org/ (though for some reason I call the kernel I package hotspot-kernel and not kernel-hotspot)

Modularity

Another thing that should be though about sooner rather than later is the fact that everyone wants their favourite feature to the community kernel, this eventually leads to a huge modules package (the symbols that must be in the kernel itself are kind of hard to avoid). It would be better to have the modules as sane collection packages (like "kernel-community-modules-nat" and "kernel-community-modules-joydev" examples above)

For example the mobilehotspot could just as well use the community kernel if Provides lines are good, also it could do away with shipping it's own kernel altogether if the community kernel could be stripped down to as minimal as possible additions to the stock kernel.
 

The Following 3 Users Say Thank You to rambo For This Useful Post: