Process Tool considered useful

[LANDAU_CHARLES@Tandem.COM]

As the inventor of the KeyKOS domain (process) key, I feel compelled to
respond.

The node (capage) is merely a storage receptacle for keys. While it is
true that a domain (process) contains a node at its root, it is no more
reasonable to expect a node to know how to construct a process, than to
expect it to know how to construct a supernode, factory, or application.

In a heterogeneous system, there could be different types of processes;
a 386 process, an R4000 process, etc. You wouldn't expect a 386 kernel
to know how to make a process key to a R4000 process. The proper way to
control this complexity is to have different creators for different
kinds of processes.

The domain tool (process tool?) is closely held because it creates only
the kind of process known to the local kernel. This is something you
might want to hide from general users, to prevent them from knowing, or
needing to know, on what type of host they are running.


------------   ORIGINAL ATTACHMENT   --------
SENT 04-28-97 FROM SMTPGATE (shap@eros.cis.upenn.edu)

I am debating the merits of the current process tool.  Norm asserts
that the process tool need not be closely held for security reasons.
If this is so, the only reason I can see for distinguishing the
process tool is that the canopener operation cannot be performed on a
kept red segment.

If this is correct, then I propose the following change to the
architecture:

   process tool => renamed to canopener
   mkprocess becomes an operation on a capage (node) key
   mkstart, mkresume become an operation on a capage key
   logical distinction between capage and process key is that
     process key prohibits operations on brand slot.

I believe this actually reduces the kernel size.

What brought this to my attention was trying to formally describe the
semantics of the capage key.


Reactions?