Jonathan S. Shapiro wrote:
On Mon, 2003-12-08 at 12:31, Hermann Härtig wrote:
ALL communications are invocations on objects. The only questions that
This "credo" clarifies the fundamental difference.
In L4 thinking, "objects" is a user-level abstraction. L4 supports a fixed minimal set of resources provided by the kernel: task(addresspace), thread, pages, ... . Mappings correspond to such kernel resources. Everything else is "second class", i.e. built on top of it using IPC. Then, allowing just "object"-invocation-like IPC(synchronous calls) is a restriction compared to arbitrary communication patterns.
In Eros, everything is and must be "invocations on objects" regardless of whether they are provided by the kernel or in user-land to the extent that user-level objects are represented by some kernel entity. Then, allowing invocation on kernel-objects only is a restriction.
Here, it is my strong belief that L4 (with all its problems that still need to be resolved) has it right! "Objects" are user-land business to the extend that clever compilers may decide to optimize away certain "object" boundaries. I have to emphasize the *belief* in the previous paragraph.
Other differences fall out of that fundamental difference:
L4 imposes the restriction that the only invocable object type is "process" (or in some cases thread).
"It is a generalization, not a restriction."
L4 does *not* (today) provide means to allow a server to extend the object name space.
But is allows servers to build arbitrary name spaces on top of L4. It is not kernel business to provide a name space for user-land objects. Name spaces are often defined by user-level standards (e.g., file ids).
- The invoker should not know the server identity. That should be known only to the file object.
- It is difficult to transparently virtualize objects when their invocation patterns are different.
We need means to transparently intercept IPC (we have several different proposals for that in the L4 community). And that is all that is needed. Arbitrary invocation patterns can be built and virtualized in user-land if IPC is really fast.
Descriptors, which *can* be used as a foundation for certain kinds of security, suddenly become extremely inefficient because they cannot be passed without consulting a third party.
Caching solves that problem. I have no problem with "descriptors". But descriptors in a micro kernel should be descriptors (mappings) on kernel resources, not "objects". The kernel can do nothing to protect "objects" since they are in the hands and at the mercy of user-land. Therefore, no need to have any notion of "objects" in the kernel.
Note the "certain kinds of security" for your tutorial in Dresden.
(process-id, server-defined-bits)
Despite the fundamental difference, the implementation ideas seem somehow similar. The sender id mechanism in the generalized mapping discussions can (at first view) be used to build server-defined-bits on top of it (see my previous email). Simply, let the server act as pager providing for the clients. But sender ids allow many more schemes.
In our thinking, the unit of protection is an address space. Why need anything else but unforgable sender ids plus control of IPC via send mappings?
Because these are architecturally insufficient to implement an efficient, secure, object-based operating system.
I do not buy this. Here is the fundamental difference again.
This is a good start, but our experience is that hierarchical restrictions of this form do not map well to the real problem space.
Hm?
--hermann