l4-hurd
[Top][All Lists]
Advanced

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

Re: Constructor v. Trivial Confinment


From: Marcus Brinkmann
Subject: Re: Constructor v. Trivial Confinment
Date: Mon, 01 May 2006 19:10:29 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

Hi,

thanks for the summary.  I only have one point to add right now.

At Mon, 01 May 2006 12:42:10 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> The trivial confinement mechanism does not provide the identification
> function at all.

It does not provide the identification function as you describe it.
However, it does allow for a different method of identification that
has been sufficient in the Hurd so far (and which is used in the Hurd
on Mach).

This method works, technically, exactly like the identification of the
constructor.  The same branding feature can be used.  However, instead
of identifying the constructor, ie the template of a program, it
identifies a single instance of a program.

For this, a program B receives, by parenthood, a capability S to a
service that it can rely on.  If it then receives any random
capabiilty T from any peer process, it can invoke an operation on S to
check if T is a capability implemented by S.  This identifies the
server implementing T as the server Z.

This method has quite different properties thatn what you are looking
for, but it does provide a means of identification, for what it's worth.

> SUMMARY
> 
> I think that the productive use case discussion must focus on the issues
> of Identification or Encapsulation, possibly in some combination. The
> bag doesn't really add any new power to the situation, and experience
> suggests that we could simply disable this without any significant
> problem.

I tend to agree.

Thanks,
Marcus





reply via email to

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