l4-hurd
[Top][All Lists]
Advanced

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

Re: Extending the problems we have with caps to endpoints


From: Espen Skoglund
Subject: Re: Extending the problems we have with caps to endpoints
Date: Tue, 11 Oct 2005 20:09:01 +0200

[Jonathan S Shapiro]
>> Note that from what I heard the L4 people do not have fundamental
>> objections against a copy operation, on the condition that it is
>> "necessary".  What is needed to convince them of necessity I don't
>> know :)

> For a while, I had them convinced that they wanted it. Then they
> looked at the required interaction with the rest of the mapping
> database and decided that it would be very difficult to add to their
> existing system.

I'm not sure who you refer to as "they" here, but I for one have no
recollection of seeing how this would be very difficult to add.  On
the contrary, as far as I can see adding support for a copy operation
only requires a couple of lines of code.  Note that I'm talking about
the Pistachio implementation here, though.  The story might be
different for the Fiasco people.

> I have been saying for years that the right solution is to get rid
> of MAP/UNMAP. For some strange reason, they have been mildly
> reluctant to adopt this proposal. :-)

I should probably provide some answer/arguments on this.  However, in
order to keep the noise level down and avoid unnecessary repeating
what's already been said, I'll have to try and get through the
existing posts on the subject first.  I would really like to know one
thing about EROS though:

When you have a forwarding object that allows you to do a revokable
copy, can the receiver of the copy operation detect that he's received
a capability for a forwarding object?  My guess is "no".  And if this
is the case, how is revoking the capability from the receiver in this
way any worse than revoking the capability using unmap?

Yes, I'm aware of the difference where the mapper terminates and
implicitly unmaps the mapped capabilities.  What I was thinking about
here was more the situation where the receiver of the capability
relies on the capability not being able to in any way be revoked by
the mapper/copier.  Have I missed some really crucial point?

        eSk




reply via email to

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