Norman, Thanks for the explanation. Yes, the receive window is very V2-ish, and has distasteful side effects. The receiver clearly needs more control. Which means that things get ore complicated when more caps are supported. I’d like to understand the specific use cases better. I accept that one cap isn’t enough, there are likely unsolvable races, which require >1 caps to be transferred atomically. My intuition is that 3 should enough to solve all fundamental problems, and anything beyond that boils down to efficiency arguments/trade-offs. Gernot
On 12 Feb 2015, at 22:19 , Norman Feske <norman.feske@genode-labs.com> wrote:
Hi Gerwin,
we’ll have an internal discussion whether we can allow more cap transfers in one IPC. I don’t remember any fundamental limitation there, but we’ll need to dig into it a bit.
great that you are considering this change!
As Tom pointed out, there will have to be some limit on the number of caps transferred, just to get a bounded and not too large WCET, but that limit can probably be quite a bit larger than 1.
How many would your application need at most, and more generally speaking, what would you think is a good limit?
I reviewed all of Genode's RPC interfaces. The maximum number of Genode-capability arguments per RPC call is 2. If I represent each Genode capability by a triple of seL4 endpoint capabilities, the kernel would need to support the delegation of up to 6 seL4 caps.
Regarding the interface, let me share my experience with other kernels. The receiver needs a way to declare the designated names for the received capabilities. Other kernels (such as NOVA and Fiasco.OC) allow the receiver to specify a single naturally-aligned "receive window" within the receiver's capability space. All delegated capabilities will end up within the window. In my experience, this approach is far from perfect. Since the receive window must be void of any existing capability (i.e., NOVA does not allow "overmap"), the receiver has to allocate a completely free window dimensioned (and aligned) with the maximum number of capabilities to expect, e.g., 4. If a capability comes in, it will populate the first slot of the receive window but the other 3 slots will remain empty. Because the window is polluted with a cap now, the receiver needs to allocate an entirely new window for the next IPC. Consequently, this approach tends to populate the receiver's capability space quite sparsely and wastes capability slots.
From my perspective, it would be much better if the receiver was able to specify a 'ReceivePath' for each individual capability. The receiver could thereby allocate each index individually instead of allocating a window of consecutive indices.
Thanks again for discussing my request within your group. I look forward to the outcome of it.
Cheers Norman
-- Dr.-Ing. Norman Feske Genode Labs
http://www.genode-labs.com · http://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments.