Re: MIG->Corba

[Farid Hajji]

> We're talking about a microkernel arch, but still I'm
> not sure if turning hurd into gnome is a good idea.
[...]
> Interoperability is a good idea, but if you bloat the
> whole code with interoperability stuff then it blows up.
You can add as much interoperability stuff between apps.
if you wish. But please keep the overhead to a minimum
when it comes to hurd servers!!

1. Porting the Hurd to non-Mach kernels (L4 is being one of
   the candidates) would be IMHO easier if the interfaces
   use plain C and are as simple as possible.

   The problem here is not the interoperability or adding
   yet another abstraction layer on top of what is already
   there. On the contrary: There is currently too much
   communications overhead already in the ports library.

2. The faster (in terms of CPU cycles) the IPC mechanisms
   are, the better! L4 and newer nuklei try to reduce the
   memory footprint to an amount that can fit in L1 (or
   at least L2) caches, avoiding in many cases cache line
   flushes.

   If you add CORBA stuff, you'll just blow the switching
   code more, greatly reducing the performance benefits that
   L4 and others are trying to obtain.

I'd humbly suggest that before we seriously consider Corba
as a MiG replacement, we simplify the existing interfaces
as much as possible. Trying to port the Hurd to L4 is a
hard enough task and I'd prefer to have to _simplify_ MIG
(requirements) and provide an L4 backend to it, rather than
having to fight with yet more complex interfaces. [Sure,
L4 has completely different characteristics as Mach, like
synchroneous IPC and lack of port-rights, so a port to L4
requires much more work than just adapting MiG, but why
make it even harder?]

> Reliability: messages *have* different semantics when
> they have different application domains. A filesystem
> has different requirements than that of a banking
> application. Still, banking can be considered a legitimate
> distributed application although it is exceedingly trivial
> to undertake. That's just client/server. A filesystem
> or a tcp server is *so* different. Requirements of an
> RPC system for distributed systems best found in tanenbaum
> I guess, also any recent distributed systems textbook.
Hah! Reliability of distributed mechanisms is a hard and hairy
domain to deal with. I've conducted some experiments with
NORMA Mach (in a cluster) and the results of crashing nodes
were not very promising. If you want to achieve reliability
at this level, you _need_ replicative algorithms and involved
techniques that are far beyond and above what CORBA even tries
to define.

> Development cost would be the most prominent here. This would
> take a lot of developer time and effort, which may be
> a hindrance in the future: when hurd needs more subsystems.
The problem with the Hurd right now is not how to extend it, but
how to _simplify_ it so that it can be more easily extended! Just
talking about MIG/CORBA hides the true problems.

The Hurd was designed from the ground up with the assumption,
that it will run on (a variant of) Mach. Mach itself is not that
bad, but it proved too slow (in terms of latency), so that it
becomes more and more necessary to port the Hurd to L4 and other
more modern nuclei. But how do you do this? If you've really
studied the Hurd code, you'd spot at least the following problems:

1. Calls to Mach are scattered amount most files of the Hurd itself.
   There is no such thing as a kernel abstraction layer (libmom
   used to be there but was revoked and not revived yet).

2. The Hurd is intimately tied to glibc (sysdeps/hurd, sysdeps/mach/*)
   and unthinkable with another libc. If you want to port the Hurd,
   you _must_ currently also port glibc.

   This is bad, because glibc has a very large memory footprint,
   effectively excluding embedded systems as a target platform
   right now.

   This is also bad, because you can't run the Hurd inside a guest
   operating system (for development purposes but also in normal
   operations) [I termed this 'libmom-over-guestos', as opposed to
   libmom-over-mach, libmom-over-L4, libmom-over-libmom etc...].

      To get an idea: hurd servers are user-level, right? So they
      should also run on top of, say Linux, *BSD etc... A small library
      (a collection of glibc's sysdeps) would serve as a thin layer
      that holds these servers togehter and that would also provide
      glue code to the guest-os in both directions.

      Even operating systems of big multiprocessors would be
      good guest-oses to the Hurd.

3. To ease porting the Hurd, it is _necessary_ to replace cthreads
   with pthreads as soon as possible! Even if this means providing
   pthreads through a library that calls cthreads. A pthreads-Hurd
   would ease the port to OSKit libraries or even RTEMS and other
   embedded-enabled systems.

I'm more than ever convinced that it will be necessary to respecify
and then reimplement the Hurd from scratch, if we want to ever get
a chance to obtain a reasonable amount of portability; be it to
other cpu architectures, to other ukernels, to guest-os(es) or to
embedded systems (I'm not even mentioning distributed systems!!).
There are just too many Mach idioms in the current overall design,
that it becomes necessary to break everyting and rewrite :-((

Finally, the biggest problem of the Hurd is that there are too few
developers! We keep talking and talking, but when it comes to writing
code, the work is done by 2-5 people at most. So how can we remedy
this situation? If you understand Hurd sources, write HOWTOs, write
docs, manpages and example translators, implement /proc (and write
a book on how you did it!), don't just cite OSF mach documents, but
write Mach tutorials. Draw diagrams (gpic is great for this) showing
how the hurd servers interact with each other and with glibc, explain
as much as you can. If you help spreading the Hurd coding know-how,
you'd bet that we'll get new people with fresh ideas very soon.

Please feel free to step forward and coordinate the Hurd Documentation
Project. There are a lot of links that can be centrally managed (some
are already, but concentrating everything at gnu.org would be best).
Besides links, some editorial work is also called for: Write (or get
someone to do it) summaries, abstracts and background informations
that help put the pieces together. Write man pages for both gnumach
_and_ libdiskfs, libnetfs, libprocfs, ... Docs are partly available
in header files, but that is a bit terse for aspiring beginners....

There is a lot of things to do and you can really help.

Regards,

-Farid.

-- 
Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Murphy's Law fails only when you try to demonstrate it, and thus succeeds.