Re: Thoughts about the new X.2 spec...

[Jeroen Dekkers]

On Sat, Feb 02, 2002 at 12:59:13AM +0100, Farid Hajji wrote:
> as most of you on l4-hurd already know, the L4 community released
> the long awaited X.2 specification which is an experimental draft
> of the upcoming final Version 4 L4 API/ABI:
> 
>   http://l4ka.org/documentation/files/l4-x2.pdf
> 
> This new spec is not implemented yet, but the L4ka team is working on
> the Pistachio kernel which should implement the final Version 4.

Yes, I already saw the announcement on the L4 mailinglists. I haven't
read the whole spec yet, but I will certainly finish reading it in the
near future.
 
> X.2 is an extremely terse, yet very clear and understandable
> document. If you compare it with X.0, you'll notice a lot of
> enhancements, not only in the API and semantics themselves,
> but also in a much improved naming of data structures and
> syscall names. X.2 specifies a generic programming interface
> (currently in a C++-like style, leaving open the issue of
> C-bindings) as well as suggesting convenience library function
> names.

I really dislike TheWayOfNamingFunctions. IMHO (and a lot of people
share my opinion, it's even in the GNU Coding Standards) that's ugly,
but it seems to be some sort standard for OO languages. I think
names_like_this are much better.

> 1: This permits us to use a 1:1 thread-mapping library. We don't
>    need to fiddle with an n:1 or even n:m model anymore. That is
>    very important, because IPC blocking/timeout semantics are
>    heavily dependant on native threads.
> 
>    I don't know what thread library we should use here. Perhaps
>    C-Threads could be adapted to this new environment, perhaps not.
>    Maybe C-Threads is not the best Threads library to use anyway?
>    Hard to tell. Please read the X.2 spec w.r.t. Threads _AND_ IPC
>    and send some feedback to l4-hurd.

This will definitely be pthreads. Cthreads will already be abandonded
in the Mach case, it's a very unportable thread library. I'm currently
working on a pthreads library, see
http://savannah.gnu.org/projects/pthreads for the code.

This library is written in a portable way like glibc is (it will
be part of glibc if it is finished), adding sysdeps for L4 would be
easy AFAICS. I will probably do it after we've a working pthreads
running on mach.

> 6: This is the ideal way to implement user-land device drivers.
>    Together with the mapping of IO pages, we've got everything
>    that is needed to fully drive most if not all hardware on
>    a typical PC.
> 
>    The ideal vision would be to have an address space (new talk for
>    task) with say, 15 interrupt handler threads. Thread i would handle
>    hardware interrupt i, passing the request further down to any
>    driver thread that registered for this interrupt, then [depending
>    on parameter settings] reenable the interrupt when the drivers
>    accepted [and optionally handeld] the interrupt. More on this
>    in subsequent discussions.

There is only one problem: time. There is just too much hardware. We
will probably have to use something like OSKit. Of course that won't
be optimal, but maybe in the long term we can write our own device
drivers (read: when everybody uses GNU/Hurd :).

There are also a lot of optimizations which makes user-space drivers
really fast. I think there is even possible to make a L4-Hurd system
faster than the current operating systems with a monolithic kernel.

> 8: This is highly recommended reading for all Hurd hackers willing
>    to understand the L4 IPC model and think of ways to change the
>    current HURD asynch model to a more efficient/streamlined synch.
>    IPC model. Even if you read the X.0 spec before, please read X.2
>    IPC spec as well!
> 
>    Sure, most of the IPC would be done by a decent code generator
>    that would ideally support IDL as input language. In this case,
>    we would have probably caught most IPC cases between client(libs)
>    and the Hurd servers. The remaining cases could still be handled
>    manually (read: through specially tailored libraries that use
>    the specific IPC semantics of X.2).

I'm still waiting for IDL4.

Jeroen Dekkers
-- 
Jabber supporter - http://www.jabber.org Jabber ID: address@hidden
Debian GNU supporter - http://www.debian.org http://www.gnu.org
IRC: address@hidden

pgpjo5zlyJfzt.pgp
Description: PGP signature