[Gobolinux-users] hotplug, usb flash sticks

Hisham Muhammad hisham at apple2.com
Tue Nov 9 19:53:32 GMT 2004


On Wednesday 03 November 2004 22:03, Jonatan Liljedahl wrote:
> BTW, submount seems like a very nice thing, shouldn't you include it in
> the distro? What are your thoughts about packages/recipes for kernel 
> modules?

This is one of our longest-standing open problems. We never reached a 
conclusion on how to tackle this, and I know everyone has their ideas about 
ti. Here's my current thoughts on the subject: (some of these are old, and 
might have already popped up in the list in the past)

PART 1: BINARY MODULES [Note: by 'binary modules' here I mean "handling of .ko 
files".]

Rationale:
modules are "disposable" whenever you change your kernel version, so it makes 
sense to me that they are 'attached to a kernel release' rather than to 
the /Programs tree. Some programs, however, "depend" on kernel modules.

Idea:
Programs could register a dependency on a module writing its name on a text 
file, say Resources/KernelModules. When a package is installed, the module 
would be fetched in a binary modules repository (the repository would hold 
modules compiled for the standard kernels shipped with GoboLinux).

gobo at example ~]uname -r
2.6.6-Gobo
gobo at example ~]cat /Program/Foo/Current/Resources/KernelModules
foo.ko
gobo at example ~]

This would mean that, during InstallPackage, it would attempt to download 
(prompting the user first, blah blah) the file 
http://gobolinux.org/modules-repository/foo.ko--2.6.6.Gobo.
It would then rename it and drop it in /System/Kernel/Modules/2.6.6-Gobo/
(at some subdirectory, I guess, but we're only sketching ideas at this point).
There could also be a 'contrib' modules repository, etc. etc.

However, I think most of the time it would not find the module (custom kernel, 
etc.) That would lead us to part 2:

PART 2: COMPILING MODULES

Rationale:
modules are "disposable" whenever you change your kernel version, so it's an 
unfortunate fact of life that you have to go recompiling all your custom 
modules every time you upgrade your kernel. If compiling a module can be 
automated, so can this boring process be. (we hope ;) )

Idea:
Ok, things are really rough at this point. But the overall idea is to have 
"something like Compile" or "an operation mode for Compile" to handle 
'drivers' in general, and app-based modules would fit in here.

What Lucas and I have in mind is something like this: the user could have a 
tree will the sources of all his/her custom modules (or loaded on demand, 
blah blah) and the recompilation of the kernel through Compile would trigger 
recompilation of each custom module. This would could be implemented in 
various different ways... a list matching .ko filenames to "driver recipes" 
is one possibility (a list matching PCI ids to "driver recipes" could be nice 
too). There are lots of other things to think about here: for example, 
compilations of modules often generate both the module and stuff to be put 
in /Programs.

In closing, this is "where we're at", I think. With some "wouldn't it be 
nice[1]" ideas, but nowhere near a concrete solution yet. More ideas are 
welcome.

-- Hisham

[1] Feel free to mentally add Pet Sounds soundtrack


More information about the Gobolinux-users mailing list