Re: secure exec

[Marcus Brinkmann]

On Sun, May 25, 2003 at 05:45:29PM +0200, Niels Möller wrote:
> Marcus Brinkmann <address@hidden> writes:
> 
> > On Sun, May 25, 2003 at 11:18:06AM +0200, Niels Möller wrote:
> > > I think it might be a significant optimization to use one bit of the
> > > reply label for an error indication.
> > 
> > Have you checked what can be expressed with the IDL4 compiler?
> 
> No, I want to *first* figure out what the right L4 protocols are, and
> then I'll worry about how to generate corresponding stubs
> automatically.

Sorry, but that is simply ignorant.  The IDL4 compiler knows a lot about
possible optimization that I don't know (and I suppose more than you, too),
and the IDL4 compiler might already support tagging and such features which
are needed to get the maximum out of the IPC.

At least I am not going to discuss the meaning of bits in the various
message registers without first studying IDL4 and the results of the L4
people in that field.  The reason I said that the label contains the msg id
(and the id of its reply) is that this is what the label is intendend to be
for and what we currently do in Mach (the rule: what is not overthrown stays
the same as a working basis applies here).

> Most protocols, I think, involve less than 16
> calls, which results in a maximum of around 1000-4000 different
> independent protocols, depending the allocation of bits.

The Hurd current Hurd alone defines 400 messages, and Mach defines over 100
(IIRC).  Some interfaces are very large (like the ttioctl interface) with
over 100 messages.
 
> Labels have to be allocated carefully without to much waste, and if
> the space gets really scarse, two protocols that it's unlikely will be
> useful on the same object can reuse the same labels. Then an object that
> wants to implement both have to use one thread for each protocol,
> which is awkward but not a big problem.

You must not use the same label for different messages.  This has nothing to
do with the server threads.

You are rolling up the issue from the wrong side.  There are still gaps in
how some very basic IPC issues should work, and you already try to define
how error codes should be returned.  This is distracting (for me) and
premature.  Please take it with Knuth: Premature optimization is evil.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/