[gobolinux-users] Kernel modules

Jonatan Liljedahl lijon at kymatica.com
Thu Aug 11 18:42:51 GMT 2005


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

/Jonatan    -=( http://kymatica.com )=-


More information about the gobolinux-users mailing list