Re: Pthread assumption + starting real port

[Niels Möller]

Farid Hajji <address@hidden> writes:

> There is only one exception where we need kernel-level threads, even in
> libmom: pagers and preempters. L4 forces us to specify pager threads
> for new threads and such threads are kernel-level LWP. External preempters
> are planned (?) is L4 specs and their use could be useful for a real-time
> Hurd variant... For this reason, I'd suggest adding a mom_thread_t to
> libmom, that represents kernel-level threads, but to restrict ourselves
> to use pthreads everywhere except for pagers etc.

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).

>     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?

> 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. 

/Niels