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

[Mike Porter <mupi@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 03 October 2003 12:16 pm, Chris Pressey wrote:
> Sorry for starting a new thread, but the original one was getting pretty
> deeply nested, and this combines a couple of issues.
>
> (While reading this, keep in mind this is an academic discussion.  In
> the end, Matt is the 800lb gorilla here, and if he wants variant
> symlinks in the DragonFlyBSD kernel, then by gum it'll have 'em.  But I
> wouldn't feel right letting that happen without presenting the case for
> alternatives first.)
>
I don't think we are talking either/or here.  There is no reason we can't do 
BOTH varant symlinks and VFS.  True, there is SOME overlap of features (VFS 
can do, probably, almost anything that variant symlinks can do) but! there 
are other considerations such as how much work is it to set up?  Are we going 
to force everyone to use VFS layers, "primarily for package management" (for 
*most* people).  For me, for exmaple, VFS is waaay overkill; all I want is to 
be able to install perl 5.8 and gcc 3.4, without killing my system compiler 
and perl interpreter.  Some of the other advantages that come along for the 
ride, such as /usr/src as a varant symlink, allow me to more easily deal with 
multiple source trees are nice, but not necessary, in the same sense.  VFS is 
great becuase you *can* take entire classes of users, and manipulate their 
directory tree (similar to a 'jail' or 'chroot') in a much more reliable 
fashion, and if you need it, then it is one of those things that you probably 
really *really* need.  For what is most likely the majority of users, this is 
not necessary; but some mechanism allowing installation of (possibly mutually 
exclusive) ports/packages is.  But why can't we have both?  there is no 
reason VFS and variant symlinks can't coexist, and the package system should 
be able to easily distinguish the two, and if VFS is set up, use that.

FWIW,

> On 02 Oct 2003 03:35:41 GMT
>
> Sander Vesik <sander@xxxxxxxxxxxxxxxxxxx> wrote:
> > Chris Pressey <cpressey@xxxxxxxxxxxxxxx> wrote:
> > > On Wed, 1 Oct 2003 17:47:44 -0600
> > >
> > If a variant symlink uses an unset variuable then the lookup probably
> > fails.
>
> Not really what I was talking about, though... they can still go digging
> around for what the symlink points to, and launch it with the full path
> when they find it.
>
depends on how the system reports variant symlinks.  If ls -l reports the 
dereferenced value, and the value is explicitly unset, or set to "" (remember 
that setting to null is not the samething as unsetting), then you would get a 
pointer to /usr/local/gcc//gcc;  sure poking through /usr/local/gcc/ would 
eventually get them a gcc, but changing permissions on the directory 
/usr/local/gcc/ to prevent execution prevents ls from showing anything, 
effectively blocking them unless they know enough to guess the directories 
below it.

> On Thu, 2 Oct 2003 02:29:19 -0600
>
> Mike Porter <mupi@xxxxxxxxx> wrote:
> > I wasn't considering this.  however, for those users, even under VFS,
> > all they have to do is 'install' the port (however we define install)
> > and they get it back.
>
> But if they can't see 'install' either... :)
>
<snip>
> Well - if they don't already have a C compiler, they can't build it from
> source.  I suppose they could find a gcc binary for DragonFlyBSD out on
> the net somewhere - but how about if I require binaries on my system to
> be cryptographically signed?
>
Then they will probably find someone who has put out a cryptographically 
signed version they could use (unless you are talking about using a signed 
version, and only allowing binaries that you have signed....I'm sure there is 
still a way around it, there is a way around anything if you try hard enough)  
the point is to make is sufficiently inconvenient that they will go someplace 
else.

> I tend to favour cleaner solutions, even if they're more work.  I also
> prefer abstractions that have real teeth (ironically, because I've been
> bitten more often by toothless ones...)  I think the solution can still
> be worked towards in a piecemeal way, I'm just skeptical about this
> particular piece of meal.
>

I think the 'cleanness' of the solution and how much 'teeth' it needs depends 
a great deal on your specific needs.  For "most people" VFS is overkill, and 
I for one would not likely use it unless it proved significantly better 
performing than native filesystem access, and no more difficult to configure.  
for my needs variant symlinks are more than sufficent.  I recognize that 
'one-size-fits-all' doesn't work well in computers, so we probably want to 
implement both.

> I'm quite willing to take the performance hit, too.  Matt has suggested
> that, with his namecache niftiness, it will be negligible anyway.
>
> > That's why ultimately doing both is a good idea.  VFS certainly has
> > its place, and will work well for a lot things.  variant symlinks will
> > do a lot of the same things (not all) and should be easier to put in,
> > heck, even I might be able to do it, if I can ever find time (although
> > with my skills, I would almost certainly break something first <(}: ).
> >  As matt said, it will address  maybe 85% of the cases for VFS, and be
> >  easier to put in, should cost less (in terms of performance), and
> >  otherwise just seems a good idea.
>
> Where's the fire, though?
>

OK, but why is it such a Bad Idea?  If it provides a benefit to most users, 
and doesn't harm anyone, why should we not implement it?  I guess the 
argument could be raised that by implementing this, we may decide it is no 
longer necessary to put in VFS, but I don't think anyone is advocating that.

> As Matt also wrote: "correct choice of features", not "just laying on
> hacks"!
>
> Perhaps it's a little unjust to call variant symlinks a "hack"; to be
> more polite, I should say that they strike me as one of those
> "incremental improvements" that would be happily adopted by FreeBSD 5.x,
> *if* people could agree on it.  It's an "easy, low impact" change that
> would provide "immediate benefits" in a "pragmatic way" and doesn't
> "make the kernel *too* much bigger and more complicated..."
>
yes, except that fBSD for whatever reason, has apparently refused to adopt it.

<snip the rest>

I do like the idea of pulling more things out of the kernel.  

FWIW

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/feXxY30jZzkECLcRAvMrAKDIdxZp9L6jPKRWuu56UuoNWtd4uwCgmDd7
OmfvgtBdFRW7dT+dig9K5ew=
=EKN4
-----END PGP SIGNATURE-----