On Wed Oct 14, 2026 at 10:35 AM JST, Eliot Courtney wrote: > On Fri Oct 9, 2026 at 8:54 PM JST, Alexandre Courbot wrote: >> The `RpcMessage` type is the right container for the `log_event` method, >> since it contains all the data we passed to it. Move it there so callers >> don't need to extract the required data themselves. >> >> Signed-off-by: Alexandre Courbot <[email protected]> >> --- > [...] >> - let function = rpc_msg.header.function(); >> - let seq = rpc_msg.header.sequence(); >> + >> + RpcMessage::parse(self.dev, msg)?.log(self.dev); > > nit: in core/interrupts.rst we say: > > ``` A drain fails when a message's framing or checksum is bad (see > "Draining the GSP-to-CPU queue"). The message stays at the queue head, > so every later drain would fail the same way, and the IRQ thread > disables vector 155 and logs the failure, which leaves the queue > unserviced until the device is reset. ``` > > So `parse()?` returning early on failure here is intentional, but I > reckon it is worth a comment, especially since the behaviour is > different to the semantics for consuming elements regularly (still > consumes and progresses for failed elements). Especially since you > wouldn't expect this behaviour to differ for a method which explicitly > "consumes every message the queue holds".
Sure, I'll add a comment. > > It looks like this is acting as some kind of implicit poisoning. Indeed, and things will look better once we add the proper poisoning container (after r000 to keep things smooth).
