You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Per [1] and [2], an "ACK" message is a variant of Error (`NLMSG_ERROR`)
message with a zero value error code and a "NACK" message is a variant
with a non-zero error code.
At TOT, the `NetlinkPayload::Ack` is meant to be the "ACK" message and
the `NetlinkPayload::Error` is meant to be the NACK message. The
`NetlinkPayload::Ack` an `NetlinkPayload::Error` variants both hold
`ErrorMessage`. This creates an opportunity for misuse and subtle bugs
where a `NetlinkPayload::Ack` can hold an `ErrorMessage` with a non-zero
code or an `NetlinkPayload::Error` can hold an `ErrorMessage` with a
zero value code.
This change improves the alignment of `NetlinkPayload` with documented
message types[2] (`NLMSG_*`) and improves type-safety by making it
difficult to misinterpret an "ACK" as a "NACK" or a "NACK" as an "ACK".
With this change, applications must check if `ErrorMessage.code` is
`None` to validate success instead of checking if
`NetlinkMessage.payload` is `NetlinkPayload::Ack`. Similarly,
applications must check if `ErrorMessage.code` is `Some(e)` to check if
the request failed (with error code `e`) instead of checking if
`NetlinkMessage.payload` is `NetlinkPayload::Error`.
[1]: https://datatracker.ietf.org/doc/html/rfc3549#section-2.3.2.2
[2]: https://kernel.org/doc/html/next/userspace-api/netlink/intro.html#netlink-message-typesFixes#15.
0 commit comments