l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pthread assumption + starting real port


From: OKUJI Yoshinori
Subject: Re: Pthread assumption + starting real port
Date: Wed, 15 Nov 2000 09:13:18 +0900

From: Farid Hajji <address@hidden>
Subject: Re: Pthread assumption + starting real port
Date: Tue, 14 Nov 2000 23:27:58 +0100

> 1. glibc is much harder to port to another platform than most of other
>    GNU software. How would you port glibc to L4? Without Unix semantics
>    on the target platform, you'll need to redo the hurd sysdeps completely
>    from scratch and that's always a _lot_ of work. Then again, why not?

  You are right, but it doesn't differ, whether you choose glibc or
another libc.
> 
> 2. Besides glibc, other C libraries are conceivable, some of which also
>    freely available. Just think of *BSD libc's, which also happen to
>    be integrated in OSKit. Ever benchmarked FreeBSD's libc and glibc?

  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.

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

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

  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.

  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.

Okuji



reply via email to

[Prev in Thread] Current Thread [Next in Thread]