[Top][All Lists]

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

Re: status of l4-hurd

From: Michael Hohmuth
Subject: Re: status of l4-hurd
Date: 03 Sep 2001 03:25:34 +0200
User-agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Channel Islands)

Farid Hajji <address@hidden> writes:

> > Porting glibc to L4 is the best option I think. It's possible to do that
> > from L4Linux to make testing easier. See also Niels his reaction on this
> > subject.

> I partly disagree with Niels here. If you manage to port glibc to L4,
> that'll be fine with me. But don't forget that L4Linux's glibc is an
> adapted port of a Linux-based glibc. This is _not_ a native L4 glibc
> that provides anothing remotely resembling the support for Hurd/Mach
> currently present in glibc. Everyting in (the backend of) glibc's
> L4Linux heavily relies upon the l4linux server. Its exactly the same
> approach that is used in the Lites emulation library in the BSD-case.

I just wanted to remind you that L4Linux is binary-compatible with
Linux, and that includes compatibility with an _unmodified_ Linux
glibc (with the int 0x80 system-call interface).  We usually use the
off-the-shelf Linux glibc that came with out Linux distribution, not
one that has been ported to L4 or L4Linux.

However, there is a port of glibc to L4Linux that replaces the "int
0x80" with a direct call into the emulation library (which is mapped
in all user processes and IPCs the L4Linux server) -- effectively
emulating the effect of "int 0x80" on L4Linux.  This version saves the
cost of a trampoline call (an extra trap into the microkernel).  (In
other words, that's the version we use for benchmarks. ;-)

address@hidden, address@hidden

reply via email to

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