Re: radical solutions

[smd@ebone.net (Sean Doran)]

The important piece of Guruprasad's architecture is that there is
a fundamental name with which one can refer to a particular resource,
no matter where it is or where it moves to in the world.

Secondly, the OS should allow client programs to use the fundamental
resource name as a handle, and deal with all the bits of mapping the 
resource into memory or I/O behind the scenes.  His analogy is processes'
understanding of the (virtual) memory addresses they use for pointers
and the like versus where a given VM resource happens to live in physical
memory in the local host (or even remotely using DSM).   That is, process
uses a handle to identify a resource, OS invisibly provides access keyed
off that handle, even if the location of the resource moves (e.g. a page
of VM can be swapped to disk, migrated to a different part of physmem,
CoWed, etc etc etc).

I don't see GSE as being particularly different from Guruprasad's
architecture, although the details of MO's proposal may be fine-tuned
(e.g., there's clever things we can do in the lower 8 bytes to make
any mapping between them and the top 8 bytes easier, and which may
eliminate use of the few bits robbed for local-to-the-site routing),
and the unstated rule needs to be stated: use only the lower 8 bytes
in your API.   This would be analogous to a 32-bit process virtual
memory space within a 64-bit physical memory space: the datum you
want may live in a page with lots of ones set in the top four bytes,
but the VM system has to present the process with 32-bit pointers,
so those just aren't seen.  This is done in some OSes for 64-bit
SPARCs which can run processes written for and compiled on 32-bit SPARCs,
for example.

	Sean.