variant symlinks vs VFS, and microkernels vs error kernels

[Chris Pressey]

On 04 Oct 2003 19:58:47 GMT
Sander Vesik <sander at xxxxxxxxxxxxxxxxxxx> wrote:

> Chris Pressey <cpressey at xxxxxxxxxxxxxxx> wrote:
> > Sander Vesik <sander at xxxxxxxxxxxxxxxxxxx> wrote:
> >> 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.

People "need" symlinks like we "need" gasoline.  It would be a lot
more accurate to say that we've grown dependent on them.

> > 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

The reason I mention it is because it's the one thing symlinks can do
that other forms of linking presently cannot...  but VFS will.

> > 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.

Regardless of the domain, I'm pretty sure no one *likes* broken links.

Personally I need a pretty strong reason to choose a system where I can
create a broken link over one where I can't.  I'm sick and tired of
shooting myself in the foot.

> >> 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.

So take your examples and prepend "vfs_ctl " to each of them.

And put a VFS entry in /etc/fstab.

And... seriously, I can't think of anything else of significance.  If
you wanted to set up a full-blown VFS jail, yes, that'd be more work. 
But I haven't seen anything that would suggest that that'd be a required
way to set up VFS.

> > 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?

Granted, it's probably trickier, but if you're allowed to reconfigure
the chunk of the VFS mount that you're considered to own, then why not?
"vfs_ctl grant <accessflags> <user> <directory>" if you like.

-Chris