Re: Getting Started with Hurd-L4

[Sam Mason]

Marcus Brinkmann wrote:
>We have done a lot of work, but most stuff
>still exists in our heads only and is not realized in code.

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.  It would export a much lighter weight set of
abstractions that what seems to be being proposed at the moment -
things like your "containers" would be implemented by the clients,
with the kernel just seeing things like "give that process this access
to this page of memory" (the originator would always have to have at
least the rights it was giving to the other process).  The reciving
process would just recieve a message saying "this process has given
you this access to this page of memory" and it would be up to the
reciving process to work out what to do with it based on previous
conversations it's been having with the process.  The originator
wouldn't then be able to revoke access to that page (there wouldn't be
the concept of a page owner, like you seem to have).  The application
would have to keep closer tabs on what pages it's shared with other
programs than with what you seem to've proposed though.

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

>Well, there are usually two definitions: Everything outside the kernel
>(user space), and everything outside the system code (untrusted user
>space).
>
>As we use L4, everything we do is user space (except for the rare case
>where we find a bug or flaw in L4, etc).  So I was assuming you meant
>the untrusted user space.

Just to make sure I understand:

Kernel space is the L4 kernel - hopefully we won't have to touch it!
because from what I've seen it doesn't seem as though getting fixes
incorporated is easy.

Untrusted Userspace - the normal set of programs that a user would
run.

Trusted Userspace - anything that an untrusted program would rely on
for general operation.  I.e. things like physmem, device drivers. . .

>You mumbled something like running a shell would be far off.  I don't
>disagree.  However, a minimal shell that does load an executable from
>a ram disk and creates a task from it will be possible quite early.
>That won't be a POSIX shell of course. ;)

That's kind of what I was expecting.

>if we are lucky, we can fake enough to compile some simple programs
>early (even if they will fail to work properly in some circumstances).

I've never really got this far, but I'm assuming that you'd want quite
a few simple little programs just so you can start to debug the other
services you've got in place.

>By the way, the C library is not a long way off.  In fact, I already
>have an older version of glibc (a year ago or so) frobbed so much that
>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?

>The nice thing about glibc is that you can relatively easy compile it
>without a complete port, and then implement the missing pieces one by
>one.

Sounds good!

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

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

>The rest (except for the other support libraries, like libhurd-slab
>and libhurd-ihash, and libpthread) is basically bootstrap junk.

You you think they're going to be fleshed out more, or will they get
dumped as things progress?

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

Cheers,
  Sam