[gobolinux-users] Kernel modules

Hisham Muhammad hisham.hm at gmail.com
Thu Aug 11 17:09:03 GMT 2005


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?

-- Hisham


More information about the gobolinux-users mailing list