Re: status of l4-hurd

[Farid Hajji]

> > 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.
Yes, this is exactly what I'd like to do: Use separate libraries,
where the Hurdish-stuff is in a OS-specific library. You're right,
glibc is already modular in this sense. I wouldn't have been able
to extract the sysdeps and combine them with FreeBSD's/OSKit's libc,
if that were not already done ;-).

> > 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?
Absolutely.

> > 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.
Of course, native POSIX operates directly on the VFS of the host OS.
Hurd's POSIX calls would be wrappers that do their own stuff completely
differently from the host OS. Currently, I'm trying to put a small
prototype together, that uses "native" POSIX calls _only_ to emulate
a block device. This block device would then be accessed through
libstore/storeio for example.

> 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.
Well, I already booted Lites on gnumach, parallel to the Hurd, giving
it its own UFS/FFS root partition. I didn't do anything fancy here,
but I expect bad things to happen when both Lites and the Hurd try
to open the same Mach device(s) and access them independently of
each other. Maybe Mach would cope with that, maybe not.

L4Linux is good if you want to have a working development system with
L4 as it's kernel. You could then develop [/port(?)] inside L4Linux
and start native L4 tasks/threads. However, as you pointed out,
this has no _direct_ relation to L4-Hurd as such.

> > 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.
I dunno if anybody really tried a port of glibc to BSD. The license
issue is not a problem: glibc would be just yet another third party
application (a port in BSD-parlance) that applications would be free
to link against. Third party apps are free to use every possible
license they see fit: GPL, BSD, whatever...

> > > 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?
Of course, read() and write() are supported the traditional way.
No RPC of any kind here. OSKit's libc is not that different from
glibc, as far as the API is concerned. As you pointed out, it would
be necessary to use own logic for read(), write() in any Hurd port.

Where's the problem?

> /Niels

-Farid.

-- 
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.