[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: status of l4-hurd

From: Farid Hajji
Subject: Re: status of l4-hurd
Date: Tue, 28 Aug 2001 03:18:12 +0200 (CEST)

> Porting glibc to L4 is the best option I think. It's possible to do that
> from L4Linux to make testing easier. See also Niels his reaction on this
> subject.
I partly disagree with Niels here. If you manage to port glibc to L4,
that'll be fine with me. But don't forget that L4Linux's glibc is an
adapted port of a Linux-based glibc. This is _not_ a native L4 glibc
that provides anothing remotely resembling the support for Hurd/Mach
currently present in glibc. Everyting in (the backend of) glibc's
L4Linux heavily relies upon the l4linux server. Its exactly the same
approach that is used in the Lites emulation library in the BSD-case.

Now I can understand that you'd like to work inside L4Linux, therefore
having access to L4 as underlying kernel for testing reasons. You'd
then incrementally replace sysdeps from L4Linux' glibc's with Hurd
specific ones (therefore running at least two versions of glibc at
the same time). This may be viable, iff you find the correct ordering
of necessary steps. If you have a plan, please post it to l4-hurd.

There are other reasons for relaxing the dependance of the Hurd from
glibc. Some of them I listed in a previous mail. Some are purely
architectural (you'd have a hard time to argue against them) and
others are practical in nature (using L4Linux is one argument
in favor of a gradual port of glibc; but other compelling reasons
exist as well).

> > There is no working code yet. Marcus ported flick to the Hurd (there's
> > a debian package) so that you could try rigt now to either compile
> > the *.defs directly or write some simple (toy) client/servers with
> > IDL on top of Mach.
> Flick doesn't have all options mig provides, compiling *.defs directly
> isn't going to work. Flick is the only IDL compiler which works with
> mach afaik.
Did you try it (I mean compiling *.defs)? I'm currently doing theoretical
work and don't have a current Hurd installation handy to test it myself.

If the *.defs use MIG-isms that are positively not present in Flick-2.1,
what about fixing the *.defs? Did you try that?

Anyway, you could always try to convert some *.defs to CORBA-IDL and try
to compile that with flick, generating Mach stubs/skeletons from the
appropriate backend. Sure, if there are portability problems with *.defs,
then they are not likely to go away just by using the IDL frontent of
Flick. Those problems would need to be fixed first.

Could you (or other readers of this) please have a try at it on your
Hurd system (both *.defs and some converted *.idl(s)) and report the
results? That would be a great help.

> > I'm playing with flick right now, and will try IDL4, as soon as it is
> > publicly released (even if it is only beta). I'd also like to try
> > http://os.inf.tu-dresden.de/~ra3/DICE/ but I didn't have the time to
> > do it yet. Right now, I'm working mostly with pencil and paper [both
> > virtual ;-)], trying to figure out how the interfaces should look like.
> We should keep to the interfaces defined at the moment as much as
> possible imho.
Yes, that is what I'm trying to do. But this is only true as far as
the *.defs interfaces are concerned. Other parts like libports etc.
would most likely wander into stubs/skeletons anyway (AFAICC).

> I don't have any experience with IDL, I'm learning the mig
> language first so I understand the currect interfaces, I have already
> learned a bit about CORBA IDL too.
That's great. Personally, I know IDL too, but I'm currently diving
deeper inside CORBA itself, especially using the C++ bindings. I'm
using the following books:
  Michi Henning and Steve Vinoski: Advanced CORBA Programming with C++
  Fintan Bolton: Pure CORBA/A Code-Intensive Premium Reference.
and of course the OMG specs as well ;). I guess that I'd have to learn
more about the C bindings as well, but right now, I'll stick to C++ ;-).

I'm not sure how much CORBA we need in the Hurd. If at all possible,
we'd have to rely upon IDL only as language for an IPC stub compiler
that would generate L4, Unix, whatever IPC mechanisms. But since the
Hurd relies upon a distributed name service and other parts as well,
writing an OS/Hurd near ORB as part of a library that links to every
Hurd task looks very appealing and intriguing as well.

Let's just fantazise for a moment: Imagine that the ported Hurd were
implemented as a set of objects that you could contact via (IDL-)
interfaces through an always available ORB. POSIX emulation would
be present in a (separate or inside glibc) C-library so that current
Unix-based programs still work but the emulation code itself would be
also CORBA-based. Extending the ORB with IIOP (or whatever would be
actual in the far future) would enable us to distribute the Hurd
over a set of loosly couple workstations! We could even migrate
tasks transparently to less-busy nodes and implement redundancy
algorithms so that the whole system is hardened against node crashes
or links going down. Hmmm.... a bright future, if you ask me!

> IDL4 looks very promising, but it's
> not available yet.
Expect a beta release soon. In the meantime, if you're impatient, you
could already try Dresden's DICE compiler (I didn't yet) with L4. Please
report to l4-hurd if you did.



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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]