Re: Shared libraries revisited

>Well, you could share code between boot programs this way. Of course
>some of them (at least the shlib server!) need to be statically linked.

Well, if you do shared libraries for VSTa you can add this. But I'd
strongly suggest doing this after "regular" programs are working well....

>This might be a good idea on a diskless system. It also doesn't seem to
>make much difference from registering them from /etc/rc. The process
>registering the shared lib may not be able to access other servers at
>that time, but it could write it from its own data segment.

So now you'd need some way to embed library images into an a.out. Something
like "dbsym" would suffice, but... is it worth the time? There shouldn't
be *that* many boot servers. In fact, my own boot.lst could stand some
trimming.

>Yes, but you may want different memory-protection schemes on different
>portions of the shared library: Code should probably be read-only, data
>copy-on-write (although shared variables might be a good idea, too).
>Maybe each library should really be a directory, where each segment is
>a file?

You are confusing mechanism with policy. The shared library server only
provides a mechanism--the provision of data, and base guarantees about
its consistency. The policy of what should be read vs. read/write
is up to the client. The critical one is that the file not be mapped
read/write. VSTa itself forbids this, so no problem. Aside from this,
why should the server care if you want to map text copy-on-write
or place your data at the wrong address?

>I generally think a process should not write into its own text segment.
>While it may be save to do so at startup, most attemps to do so later
>are probably programming errors (In these days of long pipelines and
>seperate I&D caches it is increasingly difficult to write selfmodifying
>code). It also prevents sharing of text pages
>between processes running the same program.

Yes. Sun uses mprotect() to switch access off after setup. We don't
have an mprotect() (yet) so whoever does shared libraries might
need to write one. Or ask me (nicely :->).

>Execv writes the a.out file to the shlib-server, which will relocate it
>against already registered libraries. If the relocation succeeds, the
>relocated file and the shlib can be mmap'ed and exec be called.
>If not, shlib will return a list of libraries. Execv will try to find
>them and register them in turn (which may make it necessary to register
>more libraries). After that it will again register the a.out. and exec
>it. The server can discard unused excutables and shared libraries if it
>runs out of space.

This is starting to sound like VMS--too complex! How about: execv()
uses an environment variable (remember--we have a shared namespace for
environment variables, so there can be a default, a per-user, and a
per-process, as needed) to find libraries. If it can't find a library,
it fails.

You need to look at the a.out caching VSTa currently provides. We don't
want to lose this if we can help it. See kern/exec.c, especially the
parts about FS_FID. It would be VERY desirable to reattach to an
existing pset for the shared library segment as well as the a.out
file itself. This might require FS_FID hooks in mmap() also; whoever
does shared libraries will have to ponder this. The initial bringup
doesn't need it (the pages are presumably still in the cache of the
shlib server) but I found a definite speedup when I added a.out
caching and allowed re-execv()'s to just attach to the existing
pset.

                                                Andy
Received on Fri Aug 27 12:30:55 1993