Re: Contribution to the Hurd on L4

[Marcus Brinkmann]

At Tue, 28 Dec 2004 17:07:55 +0100,
Matthieu Lemerre <address@hidden> wrote:
> > No.  The task server does not play any role in the RPC beyond
> > supplying the task info capabilities.
> 
> OK.  I didn't thought that a server could have a capability on another
> server even if it hasn't a task info capability on the later; that is
> necessary for initial communication between physmem, task and deva.

task info capabilities are a side issue in the whole discussion.  You
want to have them to have certain guarantees satisfied about the
identity of your communication partners, but that's it.

> In fact, I thought that the stub generator would not only generate the
> code needed to pass the message, but also some "generic code" (that is
> to say, the demuxer, bucket and class creation, maybe user object
> extraction from the capability object)... so that all we would have to
> write was the functions needed by hurd_cap_class_init, and the
> functions called by the demuxer.

Some of this code is in libhurd-cap-server.  You "only" need to generate
a part of the demuxer and the stubs.

> For the real demuxer, won't we be able to modify IDL4 for using our
> ABI? It seems that IDL4 contains some code for generating fast
> architecture-dependent stub code, which would be hard to re-code..

We will have to check this out.  It's not easy to answer.  IDL4 is
pretty low level.  Note that our stubs will have to be integrated
tightly with glibc for signal handling etc, and that's a bitch.  The
stubs at our high level will also have to transparently pass
capabilities along with a message, which means that one RPC can be
many IPCs to different tasks.


> >> 2/Completing libhurd-cap-server to use the task server
> >
> > To use *any* Hurd server.  (Every Hurd server is a capability server.)
> >
> 
> I was meaning "completing libhurd-cap-server where it depends on the
> task server", like in libhurd-cap-server/task-death.c, or in client-create.c .

Actually, the code in libhurd-cap-server is already somewhat in place.
The actual allocation of task info caps is not done, and not even
stubbed in, because the actual function prototype of the client stub
is not definite yet, but the comments indicate where this must be
done, and the code is all prepared for it.

There are some other things missing in libhurd-cap-server, most
notably passing caps from one client to another.

> >> 3/Completing libhurd-cap to use the task server
> >
> > Well, libhurd-cap is a framework which does not work.
> 
> Is it necessary for proper communication between servers? physmem_map
> does not use it.

libhurd-cap/ is trash code, ignore it.  It's written a long time ago
before I figured out how the cap system will actually look.  It's only
there because I have not reviewed it if it contains anything that
should not be deleted.

> > A good first project is to write your RPC.  Try modifying physmem to
> > serve another RPC (a simple echo would be fine).  Then write the stub
> > and have deva send a message.  In doing this you will better
> > understand how the IPC system works.
> >
> 
> I tried:
> 
> serving another RPC wasn't too difficult (I just had to change the
> message label in the server demuxer and adding a client stub). But :
> 
> -deva isn't started by wortel (and does not seem to be started at
>  all), so I couldn't test

Certainly deva is started, at least for me
(wortel/wortel.c::start_deva()).  Did you add it to the grub module
list after task?  Deva even contains a mini-keyboard driver that is
functional.

> -Passing a long string between deva and physmem is much more
>  complicated than just passing some words, as I need to use flex
>  pages... (I remember having read in the archives that we don't use
>  string message, and the l4-xref manual said that when passing
>  strings, Xfer page faults can occur and this is a security problem)

What we wrote is that we have not figured out completely yet how to
use string items in messages.  We certainly will support them at some
point, probably quite soon, but there is a catch as you pointed out.

What you should _not_ do is use fpages - we will use containers for
large chunks of memories for which string items are inadequate.
Containers are something like trusted buffer objects.

BTW, for your own experiments you can certainly use string items.  In
fact, as no paging happens in any of the rootservers, you won't hit
any page fault issues at all.

This is just a short reply to clear up some misunderstandings.  I am
happy to elaborate, I think there may also be some unaddressed points
in your original mail.  But maybe you just want to follow up with
questions according to your current status.

Thanks,
Marcus