Re: Pthread assumption + starting real port

[Farid Hajji]

> >   IMO, that isn't useful very much, because differences among various
> > IPC mechanisms can be relaxed by an IDL. In Hurd, IPC calls are seldom
> > used directly. The exception is only when MiG doesn't provide enough
> > information.
If all ipc between servers and glibc are specified through .defs, the
idea of an IDL with l4 backend seems reasonable. Perhaps the IDL should
specify the size (type?) of the message in any case, so that the optimal
syscall can be used?

> Hmm. If the stubs generated from the IDL use kernel calls directly,
> rather than any libmom, and all or almost all ipc uses those stubs,
> then libmom need not do anything at all about ipc¹. When you say it,
> that sounds reasonable.
I'd agree here, but would still prefer to add ipc to libmom anyway,
just in case it's needed for direct (non .defs) ipc between the components.
I'm not really sure wether we should do this or not.

> Have anybody looked into what IDL and stub generator should be used?
> Is it doable to hack some L4 backend into mig, or is it better to use
> something else?
mig is a heavy-weight idl that assumes many mach semantics. we _could_
emulate most of them in an l4 backend if we wished, but I fear that
some inefficiencies would creep in. As a first try, why not? In a later
step, a leaner idl would be a better alternative. It all depends on
what features the current hurd .defs use.

> ¹ There's still the issue of addressing the ipc correspondents.
perhaps by extending mig-generated calls with sender/receiver-ids?

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