variant symlinks vs VFS, and microkernels vs error kernels

[Sander Vesik]

Chris Pressey <cpressey at xxxxxxxxxxxxxxx> wrote:
> On 04 Oct 2003 01:52:40 GMT
> Sander Vesik <sander at xxxxxxxxxxxxxxxxxxx> wrote:
> 
>> Chris Pressey <cpressey at xxxxxxxxxxxxxxx> wrote:
>> > Yes, the level of complexity of using just varsyms and VFS together
>> > is probably manageable.  But add to those: regular symlinks,
>> > hardlinks,$PATH, chroot's/jails, unionfs/nullfs, paths and other
>> > magic *in* varsyms, shell aliases, wrapper scripts, and executables
>> > that act differently depending on the value of argv[0]... and you've
>> > got yourself quite the rat's nest.
>> 
>> links and filesystem are different layers.
> 
> One layer too many, if you ask me :)

you need to retain links. vfs will not do away with the need for symlinks.

> 
> Sure, it's fun making something on one mount appear to be on a different
> mount, but I don't think many people would say it's a recommended
> practice.  In fact I've seen the occasional rant to the contrary.


This is not, AFAICT, the main use for saymlinks

> 
> Also, I never could quite figure out why people insisted on pointer
> safety in their programming languages and referential integrity in their
> databases while happily accepting symlinks that can point to the moon.

in case of referential integrity, the answer is simple - if you avoid 
certain things that SQL lets you do, you can make sure what you have can
still be treated with realational algebra. this includes having no 
duplicates, referential integrity and so on. Pointer safety may or may not
be desirable, it depends - it isn't always. 

But neither has little to do with symlinks and wherever these need to 
point to somewhere or no. Its teh same really as with html links.

> 
> And if they can now point to ${MOON}... heh.
> 
> Of course, like argv[0], symlinks are probably too ingrained to get rid
> of completely - but that alone doesn't mean I should regard them as a
> good thing.  And if one were to try to get rid of them, then a new fork
> *would* be the place to suggest it, right?
> 
>> Ithink there are limits as to how simple you can make opertaions on
>> vfs-s, and variant symlinks would always be easier to use.
> 
> I'd be interested in hearing why you say this.

I brought a number of examples and how these would be done with variant 
symlinks in another post. Please answer with vfs based examples and 
it may become clear.

[snip]

> 
> I'm assuming that it will be possible to write a program that will allow
> you (at least as root) to tell a VFS mount to change.  That is, at
> worst: tell it to wait until it's not busy, umount itself, change its
> configuration, and remount.  If it can change its configuration while
> remaining mounted, or if it can unmount+reconfig+remount as an atomic
> operation, all the better.  Call such a program 'vfs_ctl'.

but what if you are not root?

> 
> -Chris

-- 
	Sander

+++ Out of cheese error +++