Re: Getting Started with Hurd-L4

[Marcus Brinkmann]

At Sun, 24 Oct 2004 20:35:41 +0100,
Sam Mason <address@hidden> wrote:
> The discussions about IPC have been interesting so far!  All of my own
> ideas, so far, have had something like a simplified version of physmem
> in the kernel itsel.

[...]

Well, such simplified versions are usually something you start to lay
out in front of you as a general design idea, and so did we.  But
eventually you start to see problems, and then you grow it until you
get it feature complete and bug free.

Here are two things for you to think about wrt memory management:

1) How can I perform operations (like sharing memory) with processes I
   don't trust fully, and which may not want to cooperate with me
   (both from the clients and the servers perspective).

2) Do I have enough primitive operations to allow to implement the
   POSIX interface with all its peculiar idiosyncrasies?

Both questions are central to the Hurd design decisions.  You should
find out quickly that your simple idea will neither of them, and
something more complex is needed.

> I guess that it's a bit late to be discussing things like this though!

No, but you need to catch up first because it makes sense.  Still, one
way to catch up and challenge us at the same time is to ask questions
about the design (like, why do you need to do this thing here and why
is that thing there necessary at this place).  The more specific your
questions are, the better.

[...]
 
> >I could compile it on a bare-bone L4 target and use it.  I had to hack
> >it somewhat to avoid using malloc during the startup, though, but the
> >result linked and I could use some glibc functions which don't require
> >much (or any) system support.  Originally I wanted to use them for the
> >rootservers, but that idea is kinda off the agenda for now (and
> >likely forever).
> 
> Why aren't the rootservers going to use it?  is it that glibc is just
> too big and general purpose and the rootservers are generally going to
> be doing such specalised stuff that it doesn't make it worthwhile, or
> is it something else?

Yes, and more (glibc has many dependencies).

> >Much of the design is not realized in code.  However, the parts that
> >are realized in code are usually more detailed and accurate than the
> >design doc.  The only really worthy part to look at (if you are
> >interested in this sub-topic) is libhurd-cap-server/, which contains
> >the server side of the cap implementation and is near to feature
> >complete (a crucial part, cap transfer, is missing but I have the
> >implementation details almost done inmy head for that missing piece).
> 
> I'll try and keep my eyes out!  I'm assuming this is going to be the
> basis for security in the system?

Yes, at the high level.

> >The only other part that has some merit is the wortel/startup.c and
> >wortel/wortel.c:start_task() code which shows how to spawn a new
> >program (ie, the exec protocol).  That is still under development,
> >though.
> 
> I think I found that already and tied myself in knots trying to figure
> out how it worked.

A generic description is in the hurd-on-l4.texi document (exec()
description).

> >Don't hesitate to comment on the design.  Defending it helps us in
> >understanding what we do and clarifying the documentation.
> 
> Why have you gone for a micro-kernel based design? :) OK, I'll try and
> point out things when they appear.

The more specific your question, the more specific the answer.  To
answer your question here: Because we believe in the benefits of it,
and nobody else seems to be doing it.

Thanks,
Marcus