HURD portability
Roland McGrath
>
> > Ah, yes. Libmom. I've grepped the 0.2 source tree. Nothing uses it.
> > I think this is definitely something which should be rectified, and I'd
> > love to do it myself if I had the time right now. Maybe once I move to
> > my new job...
>
> The beginnings of `libmom' in the Hurd sources are the result of an effort
> by the University of Utah Flux Project to facilitate these very things you
> are discussing, and conversations between the Hurd team and the Flux
> project. Around that time (two years ago), I moved from the FSF to my new
> job in the Flux Project, and that's *just* what I was thinking then... :-)
>
> We would very much like to work towards, not just for the Hurd, a
> portability substrate between servers and microkernels. Of course, my
> focus has gotten derailed into many other things in the past two years, and
> developing the MOM interface and microkernel implementations of it has
> languished. But it is still something my group is definitely interested in
> pursuing and collaborating on with others in the community.
This is very welcome news. Everyone seems to agree this is a good idea.
> > Actually, there are several distinct things which need doing. One is
> > that existing servers should be altered to use LibMOM. Another is that
> > LibMOM needs extending to meet the needs of the servers. And of course,
> > LibMOM should be ported to other microkernels to give HURD the
> > flexibility it deserves.
>
> The MOM interfaces are far from mature, and what you see in the Hurd
> sources are some first thoughts more than an interface that's actually been
> developed. The changes to the Hurd servers to use MOM object interfaces
> will in fact be pretty simple, mostly cosmetic.
>
> The first and largest enabling thing the Hurd needs is a full pthreads
> implementation and everything converted to use the 1003.1-1996 pthreads
> interface instead of the Mach cthreads library interface. pthreads is the
> interface other microkernels can be expected to provide; and implemented
> cleanly in GNU on Mach, it can be largely portable code that needs a
> relatively small amount of work for a new microkernel.
I would argue this is not in fact the problem of the HURD, but of libc.
Libc is the bit which has to provide a POSIX implementation, and Pthreads
are POSIX.1c (formerly .4a). If I understand correctly, glibc2 has
a linuxthreads addon which provides pthreads for the Linux kernel.
There's no reason why this shouldn't be fully integrated into glibc
properly and have libc provide a pthreads interface for any number of
kernels and microkernels.
--
Set Alias$Case Set Alias$[ |||| |MSet Alias$Otherwise Set Alias$[ \ Matthew
"" |MSet Alias$When If %0=%%0 Then Set Alias$[ "" ||MIf %0=%%0 \ Wilcox
Then Set Alias$Otherwise Set Alias$[ |||||||||||||||| ||MIf \
%0=%%0 Then Set Alias$When Set Alias$[ ||||||||||||||||
--
To UNSUBSCRIBE, email to debian-hurd-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: