[EROS-Arch] Re: design change -- IPC semantics

[Jonathan S. Shapiro]

Charlie has proposed that we revise the space bank to produce
processes/domains. I agree unreservedly with part of his proposal. On
the
rest, it's not so much that I disagree as that I see some alternatives
that
we should examine before deciding what to do.

By way of background, I considered at one time making processes be
first-class objects (i.e. even at the level of the store). As a side
effect
it became necessary for the space bank to allocate processes, so the
idea of
making this change is not new to me. It proved that introducing a new
type
at the level of the store had unfortunate consequences. However, one
(still
unimplemented) outcome of that exercise was a mental note that space
banks
really *should* allocate processes, regardless of how they were
implemented.
I could probably track down an email note to this list from that time.

While Charlie makes a number of arguments for migration into the space
bank,
the most compelling one (to me) is that the decision to implement
processes
as a collection of nodes is an accident of implementation, and that
there is
no good reason for this accident of implementation to be exposed. This
would
argue that the space bank should be responsible for allocating
processes,
and that as we get around to implementing them it should also become
responsible for allocating any other object type that we consider
fundamental. One example that comes to mind for such a new fundamental
object is an object that records a resource reservation.

A second desirable aspect of this design is that it significantly
reduces
the complexity of the primordial gordian knot. The current relationships
between process creators, constructors, banks, and clients is just
damned
ugly. It's the most difficult to understand part of system generation,
and
I'll be happy to consign it to the great bit bucket in the sky if that
proves possible.

The only negative I see is that the current space bank incorporates no
machine-specific code, and it now must do so. On balance, I think this
is a
worthwhile trade.

* Ohter Random thoughts:

An implication of this design change is that it should no longer be
possible
to "break" a process into its constituent nodes -- the process is
allocated
or destroyed all at once. I think this is good.

Another implication is that the kernel (which must trust the space bank
in
any case) need no longer consider the possibility of certain perversely
malformed processes that are possible to construct in the current
design.
The simple fact that a process capability/key exists is a priori proof
that
the process is well-formed. This alone is worthwhile, as it simplifies
some
hairy kernel code.


Note, however, that the decision about who allocates processes is
orthogonal
to the decision about who brands them.Charlie's design is a plausible
one,
and very possibly the one we should adopt. An alternative would be to
decide
that all processes returned by the space bank would be initially branded
by
the zero number capability, and that the process/domain tool can
subsequently be used to rebrand them if desired. This keeps branding and
allocation separated, which may or may not be a good thing. Offhand, I
think
this even turns out to involve the same number of capability invocations
either way.

One reason NOT to merge branding and process creation in the proposed
design
is as follows:

The factory/constructor must be able to answer the question: "Did you
create
this process?" If the replacement for this is to ask the space bank "is
this
your process" then we have a problem, because the space for the process
came
from the end user and might be used for multiple different programs. If
the
replacement is to give the space bank brand and say "does this process
match
this brand" then (a) we must frequently re-verify that the bank is
kosher
and (b) the factory must retain access to some bank. Note that the
factory/constructor must in any case hold the brand. It might perhaps be
just as simple to let the constructor hold the process tool directly.
Offhand I do not see a compelling reason to prefer either space bank or
factory, unless it might be that putting it in the factory creates yet
another reason to encourage use of the factory, which is good.

So:

Concur completely on the proposed migration of function. Consider the
process creator conceptually dead. The one remaining issue becomes the
"is
this your yield?" test, and as a collateral question the issue of who
should
hold the process tool. Further discussion?