On 2020-01-23 21:50, Millar, Curtis (Data61, Kensington NSW) wrote: >> I strongly suspect the more fundamental and general extension would be >> to remove the scalability limitation of Notifications, probably by >> generalising them to a hierarchy, i.e. you signal a sub-notification >> which then signals the higher-level notification. I?m not claiming >> having thought this through, though. > > Having thought about this a little, I think that it is useful to observe > that the case where such cases where large numbers of notifications need > to be received the receiver uses a roughly similar interface to > endpoints (seL4_Send to wait for an event and seL4_NBSend to poll for > events). > > If we allow send queues of endpoints to include notification objects in > addition to threads we could multiplex notifications via an endpoint by > binding the notifications to the endpoint. > > This could also allow for the removal of notification binding for > threads; if they want to receive both notifications and synchronous IPC > they can bind the notification to the endpoint. This design should also > work with MCS whereby donation of scheduling contexts from notification > objects would become roughly the same as donation from a thread with a > scheduling context. > > I think the cleanest implementation would be to allow a notification to > contain its own endpoint capability, similar to the manner in which TCBs > conatain capabilities. Any time an idle notification is invoked with a > send it then queues on the endpoint to which is capability refers if one > exists. Send invocations of 'active' (potentially queued) notifications > would perform the same XOR operation as currently occurs. > > When receiving on an endpoint where the first blocked object is a > notification the badge received is the badge of the endpoint capability > owned by the notification and the notification word is simply placed in > the first message register. > > Whilst I think that this (or something similar) is the most simple case > for implementing multiplexing it would have some impact on the semantics > and implementation of some objects. Even at this small a scale the > verification burden will still be considerable as this change would > impact all verified builds. > > I think further discussion and evaluation of a solution is needed before > we can determine that it is sufficiently beneficial to have this feature > in the kernel and to commit to maintaining the feature and including it > in the verified configurations. > > Cheers, > Curtis Millar >
This seems like the simplest solution, and also does absolutely everything I am looking for. Thank you! Demi
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devel mailing list Devel@sel4.systems https://sel4.systems/lists/listinfo/devel
