Re: Contribution to the Hurd on L4

[Matthieu Lemerre]

Marcus Brinkmann <address@hidden> writes:

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

Neither task nor deva was started for me. I recompiled a l4 kernel and
it worked. (Maybe I was using the old patch for pistachio 0.2)

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

I did the following: 

In the receiver (libhurd-cap-server/bucket-manage-mt.c), function 
hurd_cap_bucket_manage_mt:

  l4_string_item_t string_item = _L4_string_item (MAX_STRING_LENGTH, 
string_buffer1);
  l4_msg_buffer_t msg_buffer;
  l4_msg_buffer_clear (msg_buffer);
  l4_msg_buffer_append_simple_rcv_string (msg_buffer, string_item);

  l4_accept_strings (L4_STRING_ITEMS_ACCEPTOR,msg_buffer); /*Modified to use 
string items*/
  /* Because we do not accept any string items, we do not actually
     need to set the Xfer timeouts.  But this is what we want to set
     them to when we eventually do support string items.  */
  l4_set_xfer_timeouts (l4_timeouts (L4_ZERO_TIME, L4_ZERO_TIME));

  msg_tag = l4_wait_timeout (global_timeout, &from);


In the sender (in deva):

  l4_msg_t msg;
  l4_msg_tag_t tag;
  l4_string_item_t string_item = _L4_string_item (string_len, string);

  l4_msg_clear (msg);
  l4_set_msg_label (msg, 127);
  l4_msg_append_word (msg, cont);
  l4_msg_append_word (msg, string_len);
  l4_msg_append_simple_string_item (msg, string_item);
  l4_msg_load (msg);
  tag = l4_call (physmem);


It works well when I omit the   l4_msg_append_simple_string_item (msg, 
string_item);
line, but fail with the e field of the IPC error code set to 4
otherwise. After a while of hard debugging session (I have to reboot,
bochs won't run on my old PC), I decided to flood the mailing list a little 
more :)


I have some questions regarding the libl4 interface:

-How to create a new string item with the GNU interface? The
 _L4_string_item function does not have a GNU "name".

-What is the bug in _L4_msg_get_string_item?


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

I'm happy each time I can understand something, by myself or with your
help, and I thank you a lot to provide it to me.

But maybe I should post my messages to help-hurd? I don't want to
flood the mailing list with uninterresting questions.

Thanks, Matthieu.