[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Contribution to the Hurd on L4
Re: Contribution to the Hurd on L4
Tue, 28 Dec 2004 17:07:55 +0100
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux)
"Neal H. Walfield" <address@hidden> writes:
>> 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.
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.
>> 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
I didn't saw that physmem_map already used the containers (and thus
the capability system). And so, I thought that the capability system
was not yet functional.
>> -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.
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.
But maybe we could not call that a stub generator anymore. (althought I
remember that Mig generated the demuxer).
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..
>> 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 .
>> 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.
> 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.
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
-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)
>> 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'm impatient to be able to read it.
> 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
OK, I'm going to send them an email.