Question on "mappings as cache"

[Hermann Härtig]

Jonathan S. Shapiro wrote:

> We need to talk further about whether sender ID's are useful, but let m
Ok. This is a tough issue on which have not finally chosen which side I 
am on.
 > answer on the assumption that they are necessary.

> If sender ID's are used, then any change to a sender ID must be a
> privileged operation. It can be managed in user mode, but the software
> that does the management must be universally trusted.
No, not all changes are allowed and trust needs not be universal.
The analogy again is pager hierarchies.
Each pager must be trusted with respect to pages it manages,
the root pager must be trusted universally. It is a hierarchy.
Exactly the same with Ids.

Here is the proposal for id management in the generalized mapping scheme
that we discuss in Dresden (Marcus is redoing the internal paper I wrote 
years ago and which is exremely obsolete, I tried to include that in my 
email of 7.12., but obviously to short).

- send mapping is a "descriptor"/"capability"/"mapping"(whichever)
     that is used by its task (L4 speek for something that
     has its addressspace + at least one thread) via a local name and
     that allows to send a message to another task
   no threads are named as receiver, just the task (more options
     in my email 0f 7.12.).
- send mappings (as page mappings and all other mappings) can be
   mapped, flushed etc.
- A send mapping (for example send mapping with local name 57)
   has the form (abbreviated):
     (physical task address, Principal ID: LENGTH,VALUE)
   and cannot be inspected.
   The only operation allowed is to increase LENGTH and append
   a value to VALUE during a map operation (IPC containing a
   send mapping)
- a so called Procipal ID is used as sender id.

IPC may send out a message M by calling: send (57, M).
The kernel assigns "57.VALUE" to the first part of M where the "first 
part" has length "57.LENGTH" as a sender id.

Send mappings can be mapped from pagers to pagees. While doing so, 
LENGTH may increase, but not decrease. That way, senders further down a 
pager hierarchy can be restricted in their "Principal ID" space or - in 
other words - in which content the first part of messages may contain.
Almost arbitrary user-level naming schemes can be provided.

As a (stupid) example for a name space:
The root pager owns all ids, i.e. the LENGTH field in all its send 
mappings is 0. It may map the send descriptor to one of its pagees
X with (VALUE="85", LENGTH=8 bits). Thus  X can only use sender
ids starting ith "85". X can map the send mapping to Y with 
(VALUE="854", LENGTH= 12 bits).
In this situation, Y must be trusted with respect to the name space 
"854x..x", X with respect to name space "85x...x", the root pager with 
respect to the full name space.
X can flush Y's send mappings, thus prohibiting Y to further use
any id of space "854x..x".
This is an exact analgoy to resources provided by the kernel.
Thus, ids are treated as a kind of resource.

(I omit to discuss the possibilities and problems on the receiver side 
that need to be addressed in this scheme. That is where the various 
proposal differ and real confusion still exists at this stage of 
discussion.)

--hermann