[Top][All Lists]

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

Re: Making use of string items in the capability system.

From: Marcus Brinkmann
Subject: Re: Making use of string items in the capability system.
Date: Thu, 03 Feb 2005 14:57:00 +0100
User-agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Thu, 03 Feb 2005 15:16:41 +0100,
address@hidden wrote:
> Here is the patch which enables our capability system to use strings
> to pass messages.

Thanks a lot.

First, answers to your comments.
> -The user-defined functions must currently access the buffers by
>  reading the buffer registers. As buffer registers are "permanent"
>  (i.e. not read-once) registers, this is not a big problem, but they
>  are likely to be erased and that can be a source of bug.

True, but it is faster to use the BRs directly, and it shouldn't be a
problem if you are careful.  Being careful is a necessity anyway when
operating on messages.  Maybe one can provide both variants.

Another idea is to have a variant of the l4_store_msg call which
copies the MRs into a user provided buffer.  You could do the
translation while copying out the message.  Because the MRs are still
intact, the BRs certainly will be, too, usually.

This function could almost always be used if string items can occur,
as some translation must happen anyway as the pointers in the MR's
string items are useless at msg receive.

> So other solutions are:
> -Modifying the msg field in the hurd_rpc_context so that it points to
> the good buffers,

Yes, as I said above, this could happen automatically when copying the
MRs into the msg buffer.

> -Having an array of these pointers in the hurd_rpc_context structure.

Yes.  Actually, we may do both: The pointers and lengths of the
available buffers must be known at some level for the rpc stub to fill
in returned strings.
> I don't know which of the three solutions we should adopt.
> -MAX_STRING_ITEMS should maybe be defined in libl4/l4/ipc.h

Makes sense, although we may define a cap server symbol anyway.  The
reason is that if at all possible without extra costs, I'd like to
have the cap server interface to be pretty L4-independent wrt data
types etc.

> -I've included the changes I made to the string item buffers (those who
> are not integrated yet because of aliasing problems), because they are
> used by this patch. 

> -You have to use the Pistachio patch which ignores timeout for local 
> pagefaults.

Yes.  The other patch is indefinitely stalled due to the problems I
described, so we can use the simple patch for now, just to get the

Will look at the code soon.


reply via email to

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