Re: user configurability

[newsham@lava.net (Tim Newsham) writes:]

>I was looking through some of the lib code the other day,
>and in particular the shared lib stuff, and it dawned
>on me that in some ways VSTa is not as configurable as
>it could (should?) be. Each user is free to set up their
>own mount table to customize their environment. Some
>items, though, are accessed through fixed port numbers
>and do not allow a user to replace them. In the case
>of the shared libraries, the loader requires that libs
>exist in /vsta/lib on the partition registered as fs/root
>in the namer. Further, the namer is gotten through
>the hardwired port "1". Many other services also use
>the fixed namer port for locating things.

I guess I always assumed the namer would be global, since for arbitrary
parts of the system to "come together" there has to be something, somewhere,
which operates in a common fashion.

As for shared libraries, I absolutely agree that the system should be more
open. However, note that the base (DLL style) shared libraries don't scale
well. Coincidentally, I recently added (in the latest vsta/doc/todo) a note
to add on PIC-style shared libraries for any libraries which don't fit into
the basic system DLL set.

But anyway, the reason DLL shared libraries load in two stages was so that
the first level loader (in vsta/lib/ld.shl) could be switched from its
current basic form to something more flexible.

>I was thinking that there may be situations where it
>would be desirable to set up a completely custom
>version of the root directory. In less extreme situations
>a user may wish to provide his own lib directory.
>In the first situation, it would be nice if one could
>set up their own custom namer, or perhaps use the
>existing namer to set up a sub-namespace to use. In
>the second situation, it would be nice if the loaders
>were able to traverse filesystems to search for the
>lib directory.

I think it would be OK to come up with a way to insert a port renaming layer
on top of the process context. I think it could be done within libc,
although you'll have to add all the stuff needed to have it inherited across
an exec(). Or again, to go back to the previous discussion, this could
certainly be done within a virtualized OS environment!

>How hard would it be for the loader to get access to
>the mount table that is passed across an exec? I
>dont imagine that the fs walking code would take up
>much more space. Perhaps it could even be put in the
>second stage loader, so that the first loader does not
>have to grow at all.

Since the mount table is in libc, and the loader is used to load libc,
there's a teensy little problem.... :-> Yes, the loader could be taught to
pick through the exec argument buffer area (which, of course, is where the
mount table, among other state, comes across). But perhaps a nicer way to
deal with this is a wstat extension to namer. Imagine a "prefix=/vandys"
wstat operation to namer, which would cause it to start treating all path
lookups from that client (and all clients cloned from that one--so all child
processes would get the prefix too) as if they had an initial <prefix> put
on'em. So then you could set up your own namer mappings, and then activate
a prefix to where you set them up, and then launch a shell (or whatever).
That doesn't seem like it'd be too hard to implement, and it would let you
virtualize the namer services to a certain extent.

>It should also be quite easy to find the namer through
>a lib call that first tried to find the namer at a fixed
>path in the mount table, or perhaps through an env variable,
>and then fell back to using port 1 if that technique failed
>(for example, during the boot process).

Again, since the namer is used to find and load the code which implements
both mount tables and environment variables, you'll find yourself shoveling
quite a lot of code into this library loading code to break this dependency.

>I guess the question is, are such changes warranted?

If you could fiddle the namer prefix, you can redirect any server access
which uses a namer name. The one major thing which remains is the namer
itself (at well known port 1). But if namer lets you redirect everything
which comes to it, is it still necessary to also permit access to namer to
be redirected?

If this approach is sufficient, the good news is that you don't need much
more than a little code added to namer. This is *way* easier than messing
with the DLL bootstrap code!

Andy Valencia
Received on Tue Sep 19 22:06:25 2000