Re: L4Hurd at Sourceforge

[Farid Hajji]

> > 1) Is the fiasco kernel the right choice here? We can easily add other
> > L4 microkernels as modules.
> 
> My religion is against C++. So if there's a decent plain C/assembler
> alternative, I'd prefer that.
As said, there are more than just two or three L4 implementations
around. As long as we keep using the C-bindings and the common
API (let's agree on the upcoming API?) we'll achieve maximum portability.

> > 2) Hurd Module
> > 
> >    CVSROOT/hurd   (Hurd from official CVS)
> 
> I think it is desirable to minimize hacking all over the hurd. On the
> other hand, some components, like libports, will be quite central for
> the L4 port. So perhaps it makes sense to import it all. An
> alternative might be to create a branch or something on the official
> hurd repository. 
I agree here with Niels. libports will need to be changed, as well as
glibc to be expended. Everything else should be only touched if
absolutely necessary, and only after the VK/L4 framework is in place.

The Hurd sources would however need at least some cosmetic changes
even right now: mach_*() calls should probably be substituted with
vk_*() calls [vm_*() can be kept as-is, since we plan to provide
mach compatible VM semantics through a pager+library]. That's a lot
of changes that are not absolutely necessary, but it would be weird
to hook to mach_task_create() semantics that activate a VK/L4 task ;-).
[Anyway: we should discuss this with bug-hurd beforehand].

> Similar considerations apply to the oskit: If it's practical to use a
> released version of the oskit, and just report any bugs to the oskit
> folks in the normal way, that might be better.
That's exactly my talk. The best way would be to either use the latest
released version of Utah's OSKit, or even keep more actual with their
CVS version (do they provide anoncvs of OSKit? Will have to check this
out!).

> > 3) Is this the correct way to setup CVS? Are there any other
> > suggestions?
> 
> Another module that you'll need is glibc, or at least those parts of
> it that Farid packaged up as libhurd.
Yes, basically <glibc>/sysdeps/mach, <glibc>/sysdeps/hurd.

Here, we should talk to bug-hurd people as well, before splitting out
libhurd. If at all possible, we should do this both in Hurd/Mach and
in Hurd/L4.

> And pthreads (I don't remember current status on that).
Status was that pthreads will be taken care of by L4 developers. I expect
that future versions of L4 will provide enough threads per task, so that
a Pthreads wrapper that uses a 1:1 scheme would be easy to write. In the
mean time, we should ask L4 people about the canonical way to write
against a (subset of the) pthreads API in the L4 environment(s).

> Regards,
> /Niels

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