Re: New class of receive error

[Jason Thorpe <thorpej%me.com@localhost>]

Replies inline...

-- thorpej
Sent from my iPhone.

> On May 13, 2018, at 5:16 AM, Michael van Elst <mlelstv%serpens.de@localhost> wrote:
> 

> I don't think that's the right approach. In particular, it shouldn't
> be pushed to netbsd-8 close to the release.

I agree, this is unfortunate behavior that results in binary and source incompatibility.

> If you want reliable transport of messages, then you should use
> a reliable transport protocol.

I think the intent isn’t reliable, but rather to simply know when best effort wasn’t good enough.

> If you want complete routing information use synchronous queries
> and use routing socket messages only as an optimization.

Isn’t that what dhcpcd is doing? 

> The origin of this change seems to be the special case of Linux
> NETLINK sockets. NETLINK sockets serve similar purposes as the
> BSD routing socket for passing kernel information to userland
> daemons. Reading from them may yield ENOBUFS errors to inform
> userland that messages got lost.  This behaviour is also controlled
> by the NETLINK_NO_ENOBUFS socket flag, so it can be turned off
> again.

I think a perfectly reasonable solution to our current dilemma is to have the ENOBUFS behavior changed to opt-in with a socket option.

- thorpej