> Permissions -- permissions associated with the mapping.
> As with KeyKOS, permissions are
> subtractive; if the memory object is read
> only, you are free to map it read write,
> but it won't get you anywhere to do so.
> [ Actually, should this generate an error?
> If you are handed an RW capability to the
> object at a later time you will need to
> remap anyway... ]
In KeyKOS, the memory object could change from R/W to R/O while it
was mapped into your address space. If you then tried to store into
it, the keeper would be called to resolve the error. (Or you could
chose to get a trap to your domain keeper.) It really wasn't possible
to generate an error at the time the object was mapped.
> Object frames cannot be paged out by the kernel, because the
> kernel does not implement persistence.
KeyKOS used the same mechanism for persistance as it did to support
objects (etc.) larger than the real memory of the machine.
> One would like to provide a mechanism whereby the memory object
> manager can provide an optional storage map to the kernel describing
> where the disk storage for the object can be found. This storage map
> would allow the kernel to service memory object I/O directly, and to
> provide ageing and pageout services for memory object data. The
> storage map needs to contain disk page keys, and must therefore be
> built out of object frames. The problem is that these object frames
> are not pageable in the NewSys system, so one would like this
> descriptor to be discardable and have it be regenerated when necessary
> by the manager. This is further complicated by the need to provide
> remotely backed memory objects.
If the kernel can "call" the memory object manager, it could ask for the
optional storage map. Then the kernel could throw out the information
whenever it seemed reasonable and reconstruct it by asking the memory
object manager again. Or am I missing something?
Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz@netcom.com Los Gatos, CA 95032, USA