On 28/11/2022 08:21, Jan Beulich wrote: > In addition I think ignoring failure (and, as said by Julien, only because > of no bufioreq being registered) is (kind of implicitly) valid only for > buffered requests. Hence I'm unconvinced of the need of a new boolean > function parameter. Instead I think we need a new IOREQ_STATUS_... value > representing the "not registered" case. And that could then be used by > ioreq_broadcast() to skip incrementing of "failed".
I think I have been thinking about this the wrong way. My thinking has been that dropping an update (buffered or not) would be correct only in special cases such as timeoffset, and it would therefore generally be an error if a buffered update was directed to a handler that hadn't registered for buffered updates. The thinking in this proposal suggests that handlers are generally free to choose whether or not to accept buffered updates. I wouldn't have suspected this, but I assume then that this is perfectly reasonable in the context of Xen IO handling, so I'll go with that. Best, -- Per
