[gobolinux-users] Unionfs to replace sandbox?
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
> 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:
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
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
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
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