[gobolinux-users] Re: Kernel modules

Hisham Muhammad hisham.hm at gmail.com
Thu Aug 11 20:12:42 GMT 2005


On 8/11/05, Jonatan Liljedahl <lijon at kymatica.com> wrote:
> On Thu, 11 Aug 2005 14:09:03 -0300
> Hisham Muhammad <hisham.hm at gmail.com> wrote:
> 
> > On 7/27/05, Jonas Karlsson <jonka750 at student.liu.se> wrote:
> > > From: Kymatica <than at home.se>
> > > > From: Jonas Karlsson <jonka750 at student.liu.se>
> > > >
> > > > From: Lucas Correia Villa Real <lucasvr at gobolinux.org>
> > \> > > On Tuesday 26 July 2005 15:40, Jonas Karlsson wrote:
> > > > > > > > Is this a wanted behaviour? For me it is not...
> > > > > > >
> > > > > > > Yes, it is. This is needed so that when more than one
> > > > > > > program use the same directory name under a given prefix,
> > > > > > > both contents can be reached.
> > > > > >
> > > > > > Hmm...
> > > > > > Could you please give an example? Cant the symlinks to the
> > > content be
> > > > > > created in the folder where the symlink is pointing?
> > > > >
> > > > > Take /Programs/Xorg/Current/include/GL
> > > > > and /Programs/MesaLib/Current/include/GL as an example. If the
> > > > > former exists
> > > > > as a symlink when the latter is being symlinked, 'GL' is turned
> > > > > into a
> > > > > directory, its contents are symlinked and then MesaLib's GL
> > > > > contents are
> > > > > symlinked inside that directory.
> > > >
> > > > Ok, I undertand the problem now. But how about checking if the
> > > > link is against a subfolder in the /Programs directory before
> > > > expanding the symlinks? Isn't it so that you want to keep all
> > > > other symlinks, and dont expand them, as they are there for
> > > > compability issues?
> > > > SymlinkProgram handles all entries in /S/Links the same way.
> > > >
> > > Well, that's what I wanted to change :) (if possible)
> > 
> > I'm afraid not. The expansion of symlinks into directories under
> > /S/Links is the wanted behavior. For a straightforward example of why
> > this is important, look at /System/Links/Shared/aclocal. The problem
> > here really is with the kernel modules, not with the rest.
> > 
> > > > If /S/L/L/modules/... is a link to /S/K/modules and Compile would
> > > > install the file there, it would be the same as if you install it
> > > > directly in /S/K/modules, which is what you must do (by disabling
> > > > the sandbox).
> > > >
> > > Yes, my new recipe does this, but it's not what I prefer...
> > 
> > We've been basically doing that until now, but I see that we need a
> > better, more standardized solution.
> > 
> > Here's some ideas to start with:
> > 
> > 1) There should be NO kernel modules under /Programs.
> > Reason: programs shouldn't be packaged with kernel modules dependent
> > on the particular kernel version that happened to be running at the
> > time.
> > 
> > 2) A kernel module should be a dependency to a program that needs it
> > Implementation options: 2.1) add support to lines containing "foo.ko"
> > in the Dependencies file; 2.2) add a new file KernelModules under
> > resources.
> > 
> > 3) We should start a repository of kernel modules for the standard
> > kernels. Standard kernels = binary images published by Lucas.
> > 
> > 4) There should be a way to figure out how to compile a needed kernel
> > module when you're not using a standard kernel.
> > Proposal: add a "metadata" file (BuildInformation?) for each module in
> > the kernel modules repository indicating which recipe built the
> > module, maybe some more information.
> > 
> > 5) Suggested layout for the kernel module repository:
> > gobolinux.org/kernel-modules/
> > gobolinux.org/kernel-modules/fuse.ko/
> > gobolinux.org/kernel-modules/fuse.ko/BuildInformation
> > gobolinux.org/kernel-modules/fuse.ko/fuse.ko-2.6.12-Gobo.bz2
> > 
> > Ok, here are some ideas. What do you people think?
> 
> Sounds good, how about installation of kernel modules when Compiling a
> Recipe which builds one? Where should they be put? should we patch
> modprobe? etc... Many programs contains both kernel module and some CLI
> programs (and docs and whatever), for example FUSE has fuse.ko and
> bin/fusermount

I think they should just be put under /System/Kernel/Modules/`uname -r`.
For programs, the binaries and other files are independent of the
module version. So it could store the module under /S/K/M and the rest
under /Programs/Fuse as usual.

The connection between them would be done through dependencies. Yes,
they can get out of sync, but it's easy to verify, and a kernel
upgrade would require only the new modules to be downloaded, not the
full programs (if it were the case with some model like
/Programs/Fuse/1.6-k2.6.12.1/ ).

It will be easy to keep track of the dependencies files because the
recipes will require explicit commands to allow writing on /S/K/M. In
other words, we won't miss out kernel modules that are built without
the recipe builder "noticing" them.

-- Hisham


More information about the gobolinux-users mailing list