Re: Pthread assumption + starting real port

[Farid Hajji]

> An alternative might be to extend pthreads with something similiar to
> Solaris' notion of "bound" threads. (Some details are in the paper
> that was cited here earlier).
Sounds like a reasonable assumption.

> >     mom_message_short_t
> >     mom_message_long_t
> > 
> > The first one corresponding to L4's short messages that can be passed
> > in max. 3 registers (more on non x86 platforms) or that can be copied
> > in buffers on non L4 systems.
> 
> As the amount of data that fits in a short message varies across
> platforms, one might consider parameterizing the types and perhaps
> also the ipc functions. Like
> 
> ipc_send_1() for sending a single word,
> ipc_send_7() for sending seven words,
> ipc_send_4_vm() for sending 4 words and some memory pages.
> 
> At each use of ipc (in the code), it should be obvious which call to
> use. On L4/x86, ipc_send_4() would be a macro expanding to something
> that sends an L4 long message, while on L4/sparc it it would send an
> L4 short message. 
> 
> Does that make sense?
Yes! That is an excellent idea! IMO this is the way to go and it is much
better and much more portable in any case.

> > Another way would be to relieve auth (or if you prefer l4-mach) from
> > capabilities queries by using another self-authenticating protocol
> > between the Hurd components (examples are kerberos-tickets,
> > public-keys (stored in a keys server), with or without encryption),
> > especially considering the potential port of the Hurd to a
> > distributed system.
> 
> That's overkill for typical ipc, and would be real slow. I believe the
> right way to use cryptographic means for authentication is to use it
> to set up some kind of session, and then use some primitive and faster
> way for ipc within a machine.
> 
> If my process exchanges messages with a process on some other machine,
> It will be talking to a local proxy, using fast local security
> mechanisms. The proxy, in turn, will encode the messages in some way
> and transfer them securely to the remote machine, using whatever
> cryptographic methods that make sense. 
Here again, my point was not to use encrypted ipc (at least not on
the same host and the proxy is a good place to encrypt inter-node
messages) in general. I was more refering to signed tickets
("port rights") that would be trusted by all parties.

> /Niels

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.