Re: shared "system" libraries

[Jonathan S. Shapiro]

Oddly enough, I do not believe that the shared library problem is as
hard as Marcus describes. Perhaps I will become educated in this
discussion.

Requirements first:

  1. An application must be able to select the library versions
     that it will accept. In particular, it must be able to say
     "I have only been tested with version 5.4.9.8.2.1, and upgrades
     are not okay for me."

  2. A shared library should be retained until its last client
     lets it go.

But I think that the storage payment issue is actually not a problem. In
practice, when we install applications on a machine, they either come
from system-wide storage or per-user storage. If the application is
shared, it comes from system-wide storage. As long as this is true, we
simply need a "registry" for tracking shared library dependencies. It is
*not* necessary for every application to have its own copy of read-only
code.

There is a very natural place to do this: in the application
installer/de-installer interface.

This is really the Windows DLL version problem all over again. The main
comment I have about it is that you really need an installation
management tool in order to track this successfully. MSFT tried
*everything* short of that, and none of it worked.

So: this is a "negotiation of durability" problem and a versioning
problem. Negotiating durability is actually hard.

One point in particular: solving this requires that VCSK be moved into
the TCB. When we make a virtual copy of a space, we need a reference
counting mechanism to know when the underlying space can be reclaimed
without breaking a running program. This reference count is a downward
communication (though a minor one). Unfortunately, it violates
confinement and so needs to be handled by trusted code.

shap