Input driver configuration and use in L4Re

[Paul Boddie]

On Wednesday 23. May 2018 00.21.23 Paul Boddie wrote:
>

[L4_IPC_SEMSGCUT ("Cut send message") condition]

> I think I figured out what causes this particular error condition: the
> Registry_server class needs parameterising with Br_manager_hooks instead of
> the default hooks. Providing a parameterised Demand_t class amongst the
> template parameters for Kobject_t seems to then allocate space for an
> incoming capability. These two details are in some examples, but their
> purposes aren't clearly stated.
> 
> Unfortunately, I can't get the sent capability to be recognised. Reading a
> Snd_fpage instance from the IPC stream seems successful, but the item is
> not considered valid. I'm wondering if I need to declare something
> somewhere else, here, and perhaps pkg/examples/sys/map_irq holds the key
> to this, but I don't really follow the mechanism.

I figured this out eventually as well. It turns out that the Iostream classes 
don't support reading sent items from the stream using the operators (and 
perhaps not even using "normal" methods). So, as soon as all the words have 
been read from the message registers, only "null" items are returned.

Of course, the sent items are present in the message registers, and so it 
becomes necessary to inquire about the number of words and items, then the 
data can be read out and presented to the L4::Ipc::Snd_item constructor. 
Assignment to a L4::Ipc::Snd_fpage reference makes the sent capability 
available, and the rcv_cap and realloc_rcv_cap dance that is apparently 
necessary can then be performed. (This latter act needs the support of 
Br_manager_hooks, it would seem.)

I guess the more fancy RPC mechanisms automate this somehow, but I don't find 
the code very easy to follow. Since there is an operator method for obtaining 
Snd_item values from input streams, I would have thought that this would have 
worked and that the other mechanisms would have been using it, too, but I 
guess this isn't the case.

Paul