Re: LinuxThreads or other alternatives for the Hurd/{Mach,L4}?

[Farid Hajji]

Hi Espen,

> > Why is it such a problem for L4 to support a larger number of
> > threads?
> >  1. thread-id has too few bits?
> >  2. run-queues get too large?
> >  3. other reasons?
[...]
> 
> Future versions of the L4 API (X.2, Version 4) will not have these
> restrictions.  A Version 4 thread ID will not contain neither a task
> identifier nor a chief identifier (the chiefs & clans model has been
> abolished).  The idea is that there should be no practical restriction
> to how many threads a given task (address space) can contain.
Ah, that's very good news! This cancels the whole N:M threads library
issue at once.

As far as a Hurd/VK/{L4,Mach,Unix...} Port is concerned, we therefore
just need to switch from C-threads to Pthreads API (or preferably
just to a subset of Pthreads) and assume that a Pthreads library would
be available (or could easily be adapted) to L4 (or to any other VK
by the way).

> Conclusion: you could assume that there is no restriction to the
> number of threads a given address space may contain.  How this is
> achieved inside the kernel is not your problem.  It is something that
> we (the kernel developers) should take care of.  Of course, the
> current X.0 kernels are not really useful with the Hurd if you make
> this assumption.  You could, however, get a long way with it, and when
> Hurd/L4 has gotten somewhat closer to a useful state we will probably
> have a fully fledged Version 4 kernel to put beneath the Hurd.
Okay, let the thread issue disappear. Good luck with the X.2v4 work!
I'm glad that we don't need to fiddle with something as fragile as
a user-level thread package at all ;-).

> Conclusion 2: do not tie your L4/Hurd design too tight together with
> current L4 versions.  I.e., do not make the same mistake as when the
> Hurd was implemented on top of Mach.  Of course, everybody is pretty
> much aware of this by now, but I though it wouldn't hurt to mention it
> one more time.
You're right to insist on this. Even now that I'm trying to identify
a common VK[-API], it's quite difficult to withstand the temptation
to use L4 semantics. We'll be careful though...

>       eSk

Thanks,

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