On Fri, 2023-11-10 at 17:53 +0100, Benjamin Beichler wrote: > > > > At least in my mental model this is broken because the sender of the > > event basically has to prepare the calendar for it happening, which > > feels ... odd.
> Actually, for me, this would make kind of sense. I'm not sure I agree, I guess. To me, the sender is just telling someone else "here's something going on I want you to look at". That doesn't really mean the receiver needs to actually handle it "right away". Maybe the receiver implements a model where it's modelling an interrupt latency (which _would_ be more realistic), so it only handles the message some (small amount of) time later. Maybe it's in a polling model right now and has disabled interrupt sources, and just wakes every so often to check for messages. Maybe something else. So I don't really agree that baking a "must be scheduled immediately" into any protocol really makes sense. > Why couldn't we be more > explicit in the time travel protocol to the calendar about interrupts? > We could use the ID from the start-msg to identify um instances and > tell, in an additional msg, that we are going to trigger an interrupt at > the current time to that instance from the device simulation. But see above - I basically just don't think the sender of the event is the right position to know that information. > Another way would be, to serve such information (if the device > simulation really need it) over the facilities we already established. > Why not send the ACK as MSG_OOB or ancillary data? Don't think I understand that. Which "facilities" are you referring to here? johannes _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
