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

[Jeroen Dekkers]

On Mon, Feb 04, 2002 at 03:40:18AM +0100, Farid Hajji wrote:
> > >    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 ;-)

I think it is. :)

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

I'm not sure if it possible to make glibc+pthreads stand-alone
library. That will probably be pthreads, malloc (which is needed by
pthreads) and OS-independent things like string functions. We also
need some way of cancelling threads. I think we have to rewrite the
signal code to run on L4 for that. Roland can probably give more info
about these issues.

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

System independent code is clearly seperated from system depended
code. It should even be possible to write Linux sysdeps (If Linux gets
fixed).

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

I don't see any reason to not use native threads. We also do that in
mach. In mach we use the LDT to setup the gs segment register to point
to the thread specific data. I don't know how we should do that in L4,
I haven't studied enough for that.

Also pthreads isn't in an early stage. In fact, a lot of code is older
than 3 years. I have no idea when it will finished, as that depends on
too many things.

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

AFAIK they have an internal OSKit repository.
 
> I wished, L4Env were already released, so we could compare it to
> OSKit.

We can't compare at the moment. However, I don't think those two are
mutually exclusive. We could also write some divers, if that's needed,
and still use other drivers from L4Env or 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 ;)

We don't need an ABI interface. An API interface might be possible,
however I'm not sure if you don't have to write drivers differently if
you already know they will run in user-space on a specific
microkernel. Reading Linux code isn't my favourite thing to do either.

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

I was also thinking about small address spaces. And there is probably
more... :)

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

pgp6KBzDkmgfI.pgp
Description: PGP signature