Re: Contribution to the Hurd on L4

[Neal H. Walfield]

> I'm following the Hurd development for a while now, and I'm willing to
> contribute. I'd like first to be sure that I've well understood some
> things, and thus I have some questions.
> 
> I understand how communication is done between the servers as follow:
> 
> -Communication with wortel is done via RPC whose stubs are declared as
>  inlined function in wortel/wortel.h
> 
> -The physmem_map RPC has its stub declared in physmem-user.c in the
>  servers that need it

Yes.

> These two are done like this because the capability system cannot be
> used yet, because the task server isn't running.

No.  The task server does not play any role in the RPC beyond
supplying the task info capabilities.

The stubs are beside the servers which need them because the format is
not yet set (perhaps they will be generated by an IDL compiler).
Whatever happns, the stubs will eventually live elsewhere.  We are
just not sure where and in what form.

> Further communication between tasks would rely on RPCs based on the
> capability system.

Access to Hurdish resources relies on the capability system.  If you
want to create your own protocol to communicate, that is your
business.  We provide the capability framework which is optimized for
Hurdish interactions.

> However, I didn't find where physmem respond to physmem_map RPC.

In the container class demuxer.

> -What are the capabilities function in wortel for? Only finding for
>  the core servers the initial capabilities for the other servers?

Boot strap is part of it, yes.  But wortel also must wrap the
priviledged system calls (e.g. task and thread creation).

> -Will the physmem_map RPC be replaced by the container interface, or
>  will it be always needed for initial memory allocation by task and deva? 

physmem_map is a cheap implementation of what we actually have in
mind.

> How will you prevent a server to do a physmem_map rpc? Do you control
> the task ID numerically, assuming that deva and task's taskID are
> constant? (I didn't found where was the reply to that RPC yet, and I
> didn't understood what the create_bootstrap_caps function in
> physmem/physmem.c did...  )

Well, you need a capability.  So it is controlled through
capabilities.

> -I understand that we need a stub generator which would use
> the capability system to communicate. 

> The stub generator would generate the manager function, which would,
> on multi-threaded servers, create a worker thread executing the
> function the user has to provide, conforming to the interface he has
> given to the stub generator.
> 
> The stub generator would rely on hurd-cap-server for the server stub,
> and on hurd-cap for the client ones.

A stub generater needn't know about these details.  It just needs to
know how to include a capability into a message.  IDL4, for instance,
could work except that is doesn't have a way to consistently produce
stubs for a particular ABI.

> Am I right?
> 
> -What is the root capability? It does not appear in the hurd-on-l4
>  document. Is it the same as the master control capability, that I
>  understand as a right to do any RPC on a server?
> 
> -If I've understood, the things that must work to get the capability
> system running are, in the order:
> 
> 1/The task server, necessary to aquire task info capabilities

The capability system already basically works.  But you are right,
this part is still missing.

> 2/Completing libhurd-cap-server to use the task server

To use *any* Hurd server.  (Every Hurd server is a capability server.)

> 3/Completing libhurd-cap to use the task server

Well, libhurd-cap is a framework which does not work.

> 4/Writing the stub code generator, although not necessary to get
> communication between servers running.

Yes.

> Please, tell me if and where I could help.. If I'm not ready to write
> code, maybe can I write some documentation..

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 found some typos in the vmm.tex part of hurd-on-l4: I send you a
> diff as an attachment.

Thanks.  I have a heavily modified copy here that I need to read over
again.  I will integrate your changes into that as appropriate.

I you plan on seriously contributing to the Hurd in the future, you
will need to assign your changes to the FSF.  Please send an email to
address@hidden as soon as possible as this process can take some time.

Thanks,
Neal