Re: Mach documentation
Nathan,
> I've been reading a lot of the docs about Mach and L4.
> Most of the documentation at Utah and CMU is pretty old.
> Is there a "you must read at least these" reading list for Mach?
> I'm trying to jump to the meaty stuff as quickly as possible
> since I only have a few hours every evening to devote to
> preparation for Hurd hacking.
>
> I'd appreciate pointers from anyone who has been down
> this path before.
it all depends on you actual needs. If you're mainly interested
in Mach, you've probably read most of the canonical literature
about it. As far as I can remember, the OSF/1 documents describe
Mach 3.0 pretty well, and this is still true for gnumach. Actually,
gnumach _lacks_ support for NORMA and some newer enhancements
and the main difference between gnumach and Mach4 is the addition
of the Linux kernel drivers. I'm personally familiar with Mach4
(used it with Lites up until recently), and gnumach doesn't seem
to differ much from it (kernel drivers and some minor modifications
set aside). The gnumach interface seems to be pretty close to
Mach4's and Mach3.0's. [Roland, Thomas: is this true?]
The sources of gnumach are a good provider of information too. Most
of the important Mach functions are at least documented in their
respective header and source files. A good point to start with,
is to try to understand the Mach abstractions Task, Thread, Port,
Message, Memory Object, Device by looking at their gnumach
implementation. For example: gnumach/kern/task.{h,c} for tasks etc...
Ideally, you'll read the OSF/1 docs and gnumach sources in parallel.
You'll probably want to read more about the single OS-Server Lites,
that runs a 4.4BSD-Lite(-ish) kernel on top of Mach4. Here, Johannes
Helander's Masters Thesis: Unix under Mach -- The Lites Server, is
your main reference (in addition of the Lites sources, of
course). What got my attention in this paper was the static and
dynamic relinking of pre-compiled binaries against custom libraries,
to provide binary compatibility for programs that were linked agains
other Unix's libraries. Of course, the distinction between the
user-level emulator that caches responses from Lites and the interface
to Lites itself is pretty interesting. Anyway, as a single tasked
OS-Server, Lites is not the state of the art and the Hurd is in this
respect the natural successor of Lites.
If you're interested in the way, how the Hurd interfaces with Mach,
you'll have to spend some time reading the sources of glibc and
of the Hurd servers. Pay special attention to <glibc>/mach and
<glibc>/sysdeps/mach subdirectories. They contain the implementation
of most of the familiar Unix system calls, in terms of Mach RPCs.
Next, you'll have to understand how to write Servers/Clients with
MiG (as described in the OSF/1 documents). Armed with this, you can
look at the Server interfaces in <hurd>/hurd subdirectory. You will
almost never use those interfaces directly, but will probably prefer
to use the special libraries to access one the default Hurd servers
(e.g. libps for the proc server). Simple Unix programs do this too,
yet indirectly through glibc (Hint: try to follow the fork()/exec()
path through glibc).
You may also follow the directions in <hurd>/doc/navigating, while
exploring the sources.
The only canonical documentation about the Hurd is still the incomplete
<hurd>/doc/hurd.texi official document. Some general documentation is
currently being collected at http://hurddocs.sourceforge.net/, as you
probably know.
> Nathan Valentine - nrvale0@uky.edu
> University of Kentucky Distributed Computing Systems Lab
> AIM: NRVesKY ICQ: 39023424
-Farid.
--
Farid Hajji -- Unix Systems and Network Administrator | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany | farid.hajji@ob.kamp.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
Fermat: ...I've found a remarkable proof for this: Let x,y @#$!@$!2@ NO CARRIER
Reply to: