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

[Farid Hajji]

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

The X.2 spec specifies only C++(-like) bindings; C and other
language bindings will be included in a subsequent revision of
the spec.

For C, I also prefer names_like_this() for function names. For C++
NamesLikeThis are perfectly acceptable and widespread. I don't
like them since they look so cramped, but got used to them in
large C++ projects :(.

When I was referring to "improved naming", I was comparing them to
the X.0 names, not the way they are written! ;)

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

I wished glibc were really so portable as it claims to be ;-)

It would be nice, if pthreads could also be used as a stand-alone
library outside glibc. But do go ahead with the current effort. This
is an excellent project and it would be incredibly useful to at
least get rid of C-Threads in the Hurd. Once the Hurd uses pthreads
exclusively, life would be easier for all of us!

Wether the current pthread sources can be easily adapted to L4
X.2+ threads remains to be seen.

Please keep in mind the specific aspects of L4 X.2 (or later V4)
threads as far as possible. Especially: In L4, it will be AFAICS
necessary, to exclusively use native threads if you want to get
reliable IPC. Using LDT or other x86 specific hacks would interfere
badly with L4 too. I know of no good solution to all problems here,
but you need to be aware of future porting problems to L4 even now
at this early stage of pthreads.

Good luck!

> > 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.
> >=20
> >    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 :).

ACK.

I don't know if we should really rely on OSKit for driver code.
At least, I didn't see any new release of OSKit for a while and
their CVS sources were not updated for a very long time. Is the
OSKit project still actively maintained? If not, we'll be stuck
with old drivers until someone picked up OSKit and volunteered
to synchronize it with the most recent Linux and BSD sources.

I wished, L4Env were already released, so we could compare it to
OSKit.

If we could synchronize with Linux kernel developers to agree on
a uniform {Linux,Mach,L4,...}kernel <-> drivers interface (API and
ABI), that would be a dream! This would be at least possible for
drivers that run in separate kernel threads. But we first need to
understand the mechanics of recent Linux drivers and how they could
be integrated in Mach or L4 before we start this interface defining
business ;)

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

Agreed. L4's interrupt handling threads don't need to lock other parts
of the system while processing the int. The mapping of IO pages to
driver adress spaces is also incredibly useful and could improve
performance a lot. I'm quite optimistic that we could optimize a lot
of things here. We'll have to look at the latest Linux threaded drivers
to say for sure though...

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