Re: variant symlinks vs VFS, and microkernels vs error kernels

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Fri, Oct 03, 2003 at 03:36:49PM -0700, Matthew Dillon wrote:
:>     We aren't going to be doing anything esoteric when we implement
:>     variant symlinks... as far as programs like 'ls' are concerned, they 
:>     will simply be symlinks.
:
:Perhaps these symlinks should have a special prefix like AFS mount
:points have? That way namei can easily identify variant symlinks
:and skip the expansion process for normal symlinks. It is also
:important to provide a way to access a file with '$' or other
:special symbols. With a prefix character most applications will
:continue to work without any change.

    I think simply embedding something like ${VARNAME} in the link,
    e.g.

	ln -s '/usr/${A1}${A2}/${A3}' fubar

    Would be sufficient.  We could still have a prefix character (by
    having the 'ln' program prefix it automatically), but the namei/lookup
    code copies the symlink into a buffer anyway and checking for the 
    expansion on the fly would not represent a noticeable cost.

    Also, if a particular variable cannot be parsed or does not exist,
    we could skip that variable.  So if there is no 'A2', then the
    system might resolve the above symlink to "/usr/charlie${A2}/chan".

    And note that readlink() is unaffected.  It is only when the system
    itself is asked to traverse a symlink where the variables are replaced.
    So an ls -la will still show '/usr/${A1}${A2}/${A3}' (and thus programs
    that store binary data in symlinks will still work as expected).

:>     The VFS environments serve a larger purpose.  For example, the only way
:>     you can be sure that you have specified the correct dependancies in
:>     a port config file is to do the build in an environment which heavily
:>     restricts what the build system actually sees.  build, installation, and
:>     execution stages would all need different verification environments.
:
:With packages of the base system we can deploy chroot() for package
:building. That way only the dependencies are in place and the problem
:of base packages like gcc or perl vanishes. One thing to keep in mind
:with the compiler is the C++ incompatibility between 2.95.x and 3.x.
:Having C++ libraries in base other then libstdc++ is problematic.

    Precisely, or a jailed VFS, which would be better.

:> 
:>     Another example where a custom VFS environment would be useful is in
:>     a jailed or emulation environment.  
:
:VFS environment are the ideal solution for jails ;-) No need for a
:second system installed, just a PLIST which files are there.
:
:Joerg

    Yes, and because the namecache topology will be fixed it will be 
    possible to alias directories without creating ".." confusion in
    the system.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>