l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mach emulation


From: Niels Möller
Subject: Re: Mach emulation
Date: 16 Nov 2000 18:17:29 +0100

Farid Hajji <address@hidden> writes:

> For the time being, I'd suggest to try l4-mach + libmachemu, because
> that would save us from heavily modifying the Hurd's sources. Even
> mach_*() syscalls and -types could be provided by libmachemu now.

Doing this should also help sort out which of the Mach dependencies
are accidental ("we do it this way just because of some mach
idiosyncrasy") and which are essential for the Hurd as we know it.

> OTOH, there are reasons that would speak against adding port-rights
> to libmom, some of them obvious, some of them more subtle. port-rights
> are used in the Hurd because they are trusted entities and because they
> are implicitely passed by mach in ipc calls.

You talk a lot about trust and trusted entities etc. Of course, one
have to trust one's kernel and root but besides that, I don't think
that's the right angle for looking at port rights. My view is
something like this:

* Each port represents a resource, or object. It's encapsulated and
  its methods are defined by its rpc protocol(s).

* Initially, each resource has an owner (the task that created the
  port), and only the owner has access to the resource.

* By giving away port rights, the owner delegates access to the
  resource. A process can access the resource if and only if it has
  been given a port right by some path that is rooted at the resource
  owner. 

So we have objects, and a mechanism for delegating access to those
objects. That's the essence of ports, and that's what I believe should
be offered by libmom. Then there are send mach details, like send once
rights. I don't know if it is posible in Mach to revoke a send right,
but that is another feature that might be useful. I don't know if they
are essential or not for the Hurd.

Again, I recommend <URL: http://www.erights.org/elib/capability/ode/>.

/Niels



reply via email to

[Prev in Thread] Current Thread [Next in Thread]