[PATCH RFC 03/11] um: Use a simple time travel handler for line interrupts

[Johannes Berg]

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