Re: status of l4-hurd

[Niels Möller]

Farid Hajji <address@hidden> writes:

> I tried to relieve this problem by manually extracting <glibc>/hurd/*
> and <glibc>/sysdeps/mach/hurd into a hurdposix.so library and then
> relink/recompile Hurd programs with FreeBSD's libc+libhurdposix.so.
> It even worked (somewhat) and this is what encourages me to keep
> advocating a clean separation of glibc and Hurd-specific implementation
> of POSIX calls.

Ok, I agree that it would make some sense to split glibc in several
separate libraries, for instance

  * Basic ANSI-C support

  * Basic Posix stuff

  * Things like gethostbyname

If I understood Roland correctly, there is some separation like this
internal to glibc. E.g. one part of glibc does posix, other parts are
implemented on top of this with no additional system dependencies.

> Another reason I'd like to see this separation is that I would like to
> use OSKit's libc together with L4 to rapidly pull the components together
> that would consitute a collection of servers that behaves like the Hurd.
> Here too, it would be extremely useful if all of the Hurd's code were
> separated from glibc and relinked to OSKit's libc instead.

You'd still need those parts of glibc that you ripped out to make
libhurdposix, right?

> It's nice to have POSIX emulation, but it would be even nicer to be
> able to replace either the POSIX emulation code with stubs on
> systems that are already POSIX compliant (the VK-over-Unix case)

I'm not sure how that would work. The "native" posix functions would
not be able to handle hurd filesystems (i.e. file systems that speak
the hurdish filesystem rpc:s). So it doesn't seem terribly useful for
the Hurd.

What you might be able to do is to run a singleserver like L4Linux in
parallell, and give it a raw partition of its own to play with. But
I don't see how that fits with L4-Hurd.

> As I noted earlier, there are hardware architectures out there (massively
> parallel machines, NUMA clusters, ...) that could perfectly well run
> the Hurd servers (even distributed). But to be able to do so, we must
> use their existing extended POSIX libc's (not glibc) for the following
> reasons:

Could you give some examples?

I don't care too much about machines that are so poorly documented
that you have to rely on the vendor's proprietary OS. If you really
want to run your own OS on such systems, I think it's better to go for
some general virtual machine thing (IIRC, Linux on s390 can run either
on the bare metal, or in a virtual machine provided by the "native"
OS).

> More importantly, we don't even have a glibc port to any of the free
> *BSD kernels (Free-, Open- and NetBSD).

Has anybody given it a serious try? I'm not involved much in the BSD
world, but at least the openbsd people that I know would *never*
replace a working piece of software under the BSD-license with
anything with a more restrictive license. So I wouldn't expect them to
make any effort to get glibc working.

> > Can you explain what this libc is? My guess is that it's library
> > support for a subset ANSI-C, but no POSIX functions, no FILE *, etc?
> OSKit comes with two libc's: A smallish mini-C library that contains
> only minimal functionality like str*(), etc... and a full fledged libc
> borrowed from FreeBSD (3.x) with support for pthreads and all.

How does it support i/o? I.e. posix read() and write(), and FILE *?
Does it have it's own RPC-calls for talking to a filesystem server or
single server or something like that?

/Niels