[gobolinux-users] Unionfs to replace sandbox?

Jonas Karlsson jonka750 at student.liu.se
Thu Oct 13 07:32:48 GMT 2005

Den 2005-10-13 00:21:18 skrev Carlo Calica <ccalica at gmail.com>:

> On 10/12/05, Carlo Calica <ccalica at gmail.com> wrote:
>> On 10/12/05, Jonatan Liljedahl <lijon at kymatica.com> wrote:
>> > It feels a little bad that the only reason not to use symlinks for
>> > modules are that modprobe can't allow symlinks. Is it hard to patch?
>> >
>> Agreed.  Add it to the list to look into.  Still need to special case  
>> unionfs
> Ok.  I looked (at 3.2pre9).  modprobe and insmod don't mind symlinks.
> depmod doesn't like symlink directorys.  symlink modules is fine.
> Patching is easy and should be very maintainable.
This discussoin has been up before (I started it here:  
http://www.wotfun.com/pipermail/gobolinux-users/2005-July/001389.html) and  
there you can read that I came to the same conclusion that you did  
(symlinking modules is ok, directories is not). There were also a problem  
with SymlinkProgram that expanded the module directory  
(/System/Kernel/Modules/`uname -r`) which made the modules link at the  
"wrong place". Anyhow I dropped the idea, as Hisham gave his thoughts  
about putting modules under /Programs:

2005-08-11 19:09:03 Hisham Muhammad <hisham.hm at gmail.com> wrote:

> 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.

The whole message (which also includes some thoughts about expanding  
directories and a modules repository) can be found at  

> Two options.  1) patch modprobe.  2) Treat everything in /S/K/Modules
> as an expanded directory.  Not sure how easy #2 is.  It'll require
> some changes to some gnarly code.  See Link_Or_Expand_All() in
> Scripts/Functions/GoboLinux.

I think #2 is the way to go, but then it has to be a special case, as it  
is only the module directory you want to treat the way, all other  
directories should be expanded.

> Lucas, how should we handle that?  Maybe the recipe could check for a
> env var.  We'd need to implement hunk 1 of 01-Makefile.patch as a sed
> instead.  That would be nice anyways.  Then "NewVersion Linux 2.6.x.y"
> would work.  The only failure I had (with 2.6.13.y) was with that
> hunk.

It's the same thing every NewVersion linux :)
I agree that the versioning shouldn't be in a patch but solved some other  


Använder Operas banbrytande e-postklient: http://www.opera.com/mail/

More information about the gobolinux-users mailing list