l4-hurd
[Top][All Lists]
Advanced

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

Re: secure exec


From: Niels Möller
Subject: Re: secure exec
Date: 25 May 2003 17:45:29 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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.

And an update on the x86 impact: mr1 and mr2 are returned in
registers, so it's calls that return 2 values which will fit in real
registers if and only if the error code doesn't need an mr. So it may
work fine with the following scheme:

Number of values       Success      Error
returned (not
counting error code)

  0                    untyped=0    untyped=1; mr1 = error code
  1                    untyped=2    untyped=2
                       ; both cases have mr1 = error code,
                                         mr2 = value
  2                    untyped=2    untyped=1; m31 = error code
 ...

Using an error bit is somewhat more clean and regular, but that's a
question of taste, I guess.

> And have you considered the limited number of msg ids in the system?

The label is 16 bits.

We can use one bit to distinguish between calls and replies, and one
bit to distinguish between success and errors on replies (and then we
waste one out of four possible labels, unless we want to do operations
mod 3). So all variants counted, you have around 65000, 32000, 21000,
or 16000 possible calls. 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.

I'm not going to say that a thousand protocols ought to be enough for
everybody ;-), and I'm also not going to say that 32-bit systems will
be long obsoleted before we get into trouble. But I honestly don't
think a factor of two makes a big difference for the pain we'll suffer
when the space gets sparse.

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.

Regards,
/Niels




reply via email to

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