[Gobolinux-users] hotplug, usb flash sticks
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
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
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.
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
gobo at example ~]cat /Program/Foo/Current/Resources/KernelModules
gobo at example ~]
This would mean that, during InstallPackage, it would attempt to download
(prompting the user first, blah blah) the file
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
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 ;) )
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 closing, this is "where we're at", I think. With some "wouldn't it be
nice" ideas, but nowhere near a concrete solution yet. More ideas are
 Feel free to mentally add Pet Sounds soundtrack
More information about the Gobolinux-users