[gobolinux-users] Re: Kernel modules
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
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
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.
More information about the gobolinux-users