*Draft* DIMSUM architecture paper available

[Bryan Ford]

OK, a few first-pass comments and questions...

2. Devices: are you planning to put all device drivers in the kernel?

2. "All invocations of system-implemented object[s] are semantically atomic":
Can you flesh out exactly what this means a little more?  For example, does
it mean you can't interrupt an IPC operation in the middle and leave a
partially-copied data buffer in the receiver?  In general, I'm wary of
having the kernel widespread general commitments, like this, that often
turn out to be unnecessary and may thwart optimization.

2.1.1. Can you generate a read-only segment key from a read-write segment
key?

2.1.2. Page faults (or, in general, requests-for-data) aren't defined as
"exceptions", even though they get propagated to the segment keeper?  If
not, what are they?  (The definition of "keeper" in 2. seems to suggest
that all keeper invocations are notifications of faults...)

2.2.1. overlapping mappings:  you may be falling into one of the traps that
I think made Mach VM enormously more complicated than it should be -
requiring the kernel to deal with detecting mapping overlaps, resizing
mappings, splitting mappings, recombining mappings, etc.  It adds a
significant amount of overhead and is generally unnecessary because the
owner of the address space probably already knows what it wants to put
where.  (BTW, have you thought about the implications of mapping a small
segment A in the middle of a large segment B, thereby splitting the second
mapping in two?)

2.3. Are you going to support priority inheritance in any form?  It seems
like any kind of RT support would be difficult without it.

2.4. To whom is a read-only slot read-only?  Does this mechanism provide
any security features, or is it just a convenicence?  Since there's only
one type of key table key, and presumably you can use that key to change a
slot back to read-write at any time, it doesn't seem useful for security
purposes.  What are the benefits of read-only key table slots?

2.4. I share Charlie's (or was it Bill's?) concerns about sharing key
tables between threads.  I suspect it'll be a lot of extra complication
with little gain.  Only fairly simple services will be able to operate with
a fixed 16- or 32-slot key space; more complicated services will probably
need to use their directly-accessible slots as a cache for another, much
larger key space.  For simple services, I can't envision shared key tables
being very useful (do you have a concrete example of how they would be?),
and for complex services that want to use the directly-accessible slots as
a cache, shared key tables would be worse than useless because they would
incur a lot of inter-thread communication just to manage the "shared cache".

KeyKOS's key-management design (for which my respect is continuing to
increase :-) ) is very comparable to a RISC CPU - you have a few directly
accessible, manually managed "key registers" that are private to each
thread and are typically used as a cache; then you have much larger "key
spaces" that can be shared between threads.  Your two-key-tables-per-thread
design seems akin to a processor splitting its 32-register file in two and
allowing each half to be shared arbitrarily with other processors in an
SMP system.  On a RISC processor this would be an implementation nightmare
with very little real benefit - which is why nobody does it. :-)

2.5.1. available/waiting/blocked/disabled states:  Are these exactly the
same terms KeyKOS uses for the equivalent states?

3. 16K message data limit:  Why the increase?  Allowing more than one page,
I suspect, will be very little less complicated to implement than no limit,
whereas there are some real simplicity (and maybe performance) benefits of
a no-more-than-one-page limit.  If you're going for fully atomic,
nonpreemptible IPC, you now have to lock down up to five pages on each
side (assuming a 4K page size).  Furthermore, if you want to leave room for
user-level device drivers, then IPC must be both preemptible _and_
interruptible, or neither, because interruption is equivalent to
preemption.  Based on back-of-the-envelope calculations, with 4K transfers
you could probably get away with nonpreemptible, noninterruptible IPC paths
on reasonably fast machines for most types of hardware; with 16K transfers
you'd really be pushing it.

Basically, I recommend either increasing the limit to infinity or leaving
it at one-page-max.  (If there are machines you care about with pages less
than 4K, then decrease the limit to that size.)

7.1. sensory keys:  is this mechanism supported in any way for non-system
objects?  For example, if a key table contains a start key, and someone
with a sensory key to that key table tries to read that start key, does the
kernel have any way of interacting with the owner of that start key (or
someone else) in order to turn that start key into the appropriate
equivalent "sensory" version of the start key?  It seems like the sensory
mechanism would be severely limited, and would violate encapsulation, if it
only works for kernel objcts.  (For example, you can no longer invisibly
interpose on a kernel object, and have your start keys work right when
"sensed".)

One obvious way around this would be to define one of the eight data bits
associated with any start key as the "read-only" bit.  (Or add a ninth bit
if there's room in the key.)  The kernel would automatically set that bit
when a sensory key is used to retrieve a start key.  The server can then
interpret that read-only bit in whatever way is appropriate for the type of
object it implements.

9. First of all, I'm not sure it's necessary or useful for a
capability-based microkernel to specify any notion of "users" or
"authentication" beyond the basic capability mechanism, even if
capabilities aren't persistent.  Let high-level servers and OS
personalities sort that out.

But given that authentication has to be defined at some level, you may want
to check out the Hurd's authentication system.  It provides the basic
functionality you describe in section 9, but in what I suspect may be a
more general way.  Naturally it's geared towards Unix-style authentication,
but it could be used in other ways as well.  (I haven't studied it
extensively though.)

				Bryan