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