DragonFly kernel List (threaded) for 2003-10
Re: variant symlinks vs VFS, and microkernels vs error kernels
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.
> 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.
> 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.
> While it is possible to use variant symlinks to approach the such
> environments, so many paths would have to be symlinked that it would
> really be more of a burden and less of a benefit.
> Matthew Dillon