Re: Pthread assumption + starting real port

[Farid Hajji]

> I think it would be good if you started with a draft of the libmom
> interface. I think that would help others, and perhaps also yourself,
> to understand what you want to do.
I'll send you a list of libmom interfaces together with a specification
of the new auth server in a few days. The libmom interface is not
complete yet and we must consider a few changes/additions when we
redesign (or review) other parts of the Hurd.

> My list of things that belong in libmom are, in random order:
> 
> 1. Threads
> 
>    Preferably pthreads.
Sure. Most of the Hurd should use the Pthread API for maximum portability.
The same holds for mutexes and condition variables. I'd suggest though that
pthreads remains a library separate from libmom so that it can be
developed/ported independently for L4, Mach, glibc, libc, guest-os, ...
Logically, pthreads would be part of libmom.

One advantage of using pthreads is that this would also facilitate developing
and porting parts of the Hurd to libmom-{guestos-with-pthreads-support}.

pthreads are _not_ kernel threads and thus don't have unique global thread-ids.
This is important to know. If we use pthreads, it would not be possible
to identify a single thread of a task from outside the task. IMO, this
is okay, since tasks are to be identified by their IPC entry-points, not
by specific threads that service these IPCs. It is sensible to do it that
way, so we are free to choose the thread-model of each server depending on
its work-load and -kind.

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.

> 2. IPC
> 
>    Ideally, the IPC-service defined here should not assume any
>    particular microkernel, but it has to make the assumptions needed
>    to implement the service without adding too much extra overhead.
Agreed. Basically we need sending and receiving IPCs
(mom_ipc_send(), mom_ipc_receive()), timeouts and
message types. I'd prefer to use only one kind of message
type mom_message_t, but thinking more about it, I'd prefer
to use two kind of messages anyway:

    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. The second one corresponding to L4 long
messages that need to be passed in a page or (on non-L4 systems) be
referenced through a pointer/VM subsystem.

Distinguishing betwwen both kind of messages is important for efficiency
reasons, as well as forcing us to rethink the format of the messages
that should be passed to Hurd servers. Ideally, we'll redesign the Hurd
IPC requirements in such a way, that mom_message_short_t are preferred,
leaving mom_message_long_t for comminication setup etc. (more on this
later).

> 3. Ports
> 
>    Some way to manage ports and send rights, transfering port rights,
>    waiting for messages on any one of a set of ports, etc. This should
>    be guided by the operations Hurd servers need, not on the services
>    that happen to be provided by Mach. The entire security of the Hurd
>    is based on port and port send rights, so I suspect they have to be
>    supported.
I'm somewhat ambigouus about the need of libmom-managed capabilities or
port rights. I agree with you that the security of the Hurd is currently
intimately tied to port rights, but I think that auth should be expanded
to manage capabilities as a trusted entity. 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. I didn't made up my mind on this
yet, because of a trade-off between efficiency/speed and scalability/
distributability.

> 4. Hardware
>    
>    Some hooks for attaching interrupt handlers to the system,
>    accessing raw hardware, etc. I imagine it is difficult to do this
>    well and have it work efficiently independent on the microkernel
>    used.
Agreed. We'll have to look at L4, Mach and other ukernels to get an idea
what is commonly used/required here. We should talk more about this.

> 5. Memory
> 
>    Mechanisms for setting up, sharing and transferring pages of
>    memory. Hooks for pagers. The Hurd implementation of fork() may
>    provide some requirements (I think one may want to do hairier
>    things than fork(), but at a minimum one has to support the
>    features needed by fork() and mmap()).
That's right. It may be best not to rely on any fancy stuff in libmom,
so that libmom itself can be ported more easily to other platforms. Not
using VM tricks provided by specific ukernels would be silly too. This
is a difficult question.

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