[gobolinux-users] Unionfs to replace sandbox?

Carlo Calica ccalica at gmail.com
Thu Oct 13 22:33:22 GMT 2005

> > Andre, its your code.  How bad is that change?
> I did'nt got the exact point here. Could you explain the cenario a
> little bit more?
> Where would the modules be, and where/how would they be linked?

First generally,  How difficult would it be to extend
Link_Or_Expand_All() to treat all directories as expanded and only
symlink files.  There would be an additional parameter to the function
on which behavior to use.

Then there's the problem of where these modules would live.  Keeping
them in /Programs/Foo/1.0 along with their support binaries doesn't
make sense.  They need to be versioned to the running kernel when they
were built.  Keeping them outside of /Programs doesn't make sense
either.  People are used to package management inside /Programs and
kernel modules are really a special case of package management.

Here's what I'm thinking (not very well thought out):

Compile Unionfs
   <build process>
   PrepareProgram -t KernelModule 0.4
      <scan write dir, copy files to /P/KernelModule>
         <Finds /S/K/Modules>
            PrepareProgram -t KernelModule-KMOD 0.4-`uname -r`
            <copy modules to /P/KernelModule-KMOD/0.4-`uname -r`/KernelModules>
              <symlink KernelModules into /S/K/Modules>
   <add KernelModule-KMOD to KernelModule Dependencies>
# end of Compile

In the above, `uname -r` should be replaced with the directory found
in $sandbox/S/K/Modules.

This makes kernel modules just another package with special naming.  A
few changes to Dependencies (to special case KMOD suffix) and that
should be it.

This is much less work than making kernel modules a different type of
package installed in a different hierarchy (as discussed sometime ago,
and never implemented).  I think its less confusing (one less thing to
learn) as well.

Carlo J. Calica

More information about the gobolinux-users mailing list