Re: Hurd on Mach on GNU/Linux (verion 0.0.0)

[Farid Hajji]

> > On the l4-hurd mailing list, we're discussing the need for and form of
> > a layer between the [micro]kernel and the Hurd that will isolate the
> > Hurd from a specific kernel that it is running on top of. I called
[snip]
> 1 - You didn't mention it but won't there have to be IDL bindings to the VK 
> IPC facilities (assuming hurd begins using IDL instead of mach definition 
> files). Or will each version of the VK (POSIX, Mach etc) have separate IDL 
> bindings?
Since IPC is highly VK-backend dependent, the generated stubs and skeletons
will of course largely vary among the various VK implementations. Actually,
some implementations could use Flick, others DICE or any other suitable
IDL compiler.

As far as the bindings are concerned, as long as the IDL compiler is
CORBA/OMG compliant, the bindings should remain the same, regardless
of the specific stub implementations. In other words: IDL->C will always
generate the same C-bindings; IDL->C++ standardized C++ bindings etc...,
exactly as specified by the OMG specs.

Practically, very few suitable IDL compilers with L4 support currently
_are_ fully CORBA/OMG compliant. Therefore, there will be some variations
in the bindings too. If this happens to be the case, we'll have to
either write our own IDL compiler, adapt an existing one or hide the
compiler-dependent bindings inside library functions/macros, which will
then be the definitive bindings w.r.t. the Hurd.

> 2 - Wouldn't the VK be better off as a seperate but related project to hurd. 
> It doesn't sound hurd specific but rather a very useful library. This might 
> help to attract developers from other projects which might make use of it. Of 
> course one would have to be careful to keep it small and specific. (This is 
> of course to do with politics and management so it's really none of my 
> business but just wondering).
Of course, a VK is not only useful to the Hurd/L4 port, but would be a
general layer useable on top of (hopefully) every microkernel [or even
POSIX]. Since there is no project going on at the moment to provide
something like a VK (at least nothing I'm aware of) and since we need
VK-infrastructure in the Hurd/L4 port _now_, we should start our own
VK work now and evolve it up to a point where it can spin off to a separate
project. Our work right now would also serve as a prototye for the
requirments of a generic VK.

> 3 - Is there any timeframe to actually start righting code for l4-hurd. I 
> know there are no absolute timeframes but any idea?
No timeframe has been set, since this is a fully voluntary work. Some
constraints are present though:

 1* bug-hurd people should migrate from mig to flick. This can be done
    immediately, since flick-1.x (and also 2.x, which we won't use on
    L4 at the moment) already supports Mach.

 2* l4-hurd (or l4ka, l4-hackers) should write a [U]VM pager
    and driver support. The driver support will have to wait
    for the L4Env group at Dresden to release actual code and
    papers. The pager could be started right now [but see below]

 3* We're waiting for a standardized C-API for L4 (V2) to base
    real work on it. At the moment, some of us are playing with
    L4Ka (Hazelnut) to get used to the L4 environment, but the
    C-API may (and most likely will) change in V2.

So 1 can be done immediately, 2/pager could also be implemented
right away. 2/drivers and 3 depend on the L4 people's timeframe.

> Jonathan Hunt

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.