Re: Pthread assumption + starting real port

[Farid Hajji]

>   I haven't. But if you really want to work on Hurd, it would be
> better to improve glibc, even if glibc were slower than FreeBSD
> libc. Don't forget that Hurd is a part of GNU.
I'm sorry, but this just sounds like a religious argument here.
All GNU-Software is pretty much portable and doesn't _require_
glibc, even if it can work with it. I see no reason why the Hurd
should be an exception here.

> > 3. Retargeting the Hurd to libmom, relaxing the glibc dependancy would
> >    permit to use Hurd/L4 as a drop-in replacement "kernel" for existing
> >    non-glibc based systems. Just consider Lites/rtmach, which can execute
> >    the same FreeBSD binaries transparently without recompiling. If the
> >    Hurd were independant of glibc, it could well run binaries of systems
> >    that are not linked against glibc by trapping the native syscalls and
> >    redirecting them into libunix (just like Lites work).
> 
>   Hmm, that's interesting, but I don't see what is the benefit from
> running Hurd on FreeBSD.
That was not my point. I'm saying this: If you've got a system of already
compiled binaries (be it *BSD, Solaris, or whatever) which links to a
C library of some kind, it should be possible to:
  1. use the Hurd as a substitute "kernel", boot L4 (or whatever), the
     Hurd and let the original system bootup and run. The target system
     shouldn't even notice that is is running on top of a different
     kernel. [Think of a lot of software that runs on only one kind
     of system, either because it is non-free or because porting it
     proves too difficult].
  2. Running the Hurd inside a guest-os permits to use a machine as a
     development system. It also permits to run "Hurd-linked" binaries
     (which we all hope would soon become widely available) inside
     foreign machines/platforms, to which L4/libmom was not ported yet.
     Just think of some supercomputers and other systems, where porting
     L4 and the Hurd/libmom to it would prove very difficult (e.g.
     lack of system documentation!) and where it would be very useful
     to run the Hurd in guest-os mode.

> > I acknowledge that the C library plays an important role in the design
> > of every OS and that calls to C library functions mostly end up in
> > syscalls.
> 
>   This is not true. Glibc has many, many functions and macros which
> don't call system calls (e.g. see locale, math, string, crypt, etc.).
All this stuff is good, but most of it is part of a standard spec. of
a POSIX-like C-Library. Some of it assumes 32-bit architectures (though
_that_ can be fixed). The problem is not with what is available in
most C libraries, but with that what is _not_ available outside
glibc. Like other GNU Software, it seems to me unreasonable to
blindly assume that we're all going to use the same powerful glibc
in every case.

>   FYI, I asked that question to you, because of this. I didn't know
> where you would steal, say, strncmp, if you don't use glibc.
Yes, I understand why you're asking. That's the reason I'm looking
for a subset of functions present in all most commonly used C-Libraries
that can be safely assumed available and then restrict the Hurd's code
to that subset. There is no reason to use fancy stuff gratuitously.
That would break portability and flexibility.

As a first step, I'd suggest to extract the mach and hurd sysdeps from
glibc into libhurd and libmach and then scrutiny the Hurd code for
truly conservative use of the rest of glibc. Each used function of
(the rest of) glibc should also be present in at least one other
non-glibc C-Library or it should be implemented in terms of more
common functions.

This work could be started right now, while some of us are still
thinking about architecture issues and experimenting with single
components. Could we do this?

BTW, where can a specification of a minimal C-library (pure or
with POSIX extensions) be found? I don't have that much money
to burn for the official standards documents ;-)

>   For now, I believe that this would be ultimately the best: we use
> glibc, but the system-dependent functions and declarations use libmom,
> instead of using a underlying microkernel directly. libmom should be
> included in Hurd. So glibc relaxes differences among various
> architectures, while libmom (Hurd) relaxes differences among various
> microkernels.
That sounds acceptable to me, with the addition that the system-dependent
functions should be moved out of glibc into libmach and libhurd (if
possible).

-Farid.

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