Re: ping: sendto: No buffer space available

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> The UNIX kernel should endeavor to provide the userland with as much
> information about what's going on as possible, so that the
> application programmer can decide what to do, [...]

In general, I agree.  If the AF_INET/SOCK_DGRAM API were being designed
today, I might well agree with you.

But it's not.  Thor is right: this is an API change that would break a
lot of programs very badly.

If you really want to expose this information to userland, I think the
right way to do it is a socket option (UDP level, maybe? not sure) that
allows applications to configure a socket such that sends can block
(blocking) or return ENOBUFS (nonblocking), with the default being to
silently drop the packet, ie, what existing code expects - just as if
the queue-full condition had occurred in a switch or intermediate
router rather than on the local host.  That existing code reports
ENOBUFS as if it were any other socket send error indicates that it's
written to an API that doesn't expose such non-errors.

> Ping(8) is a network test and measurement tool.  Clearly, it falls
> into the "will request non-blocking I/O" class, [...].

It's not clear to me.  Quite aside from whether it actually needs
nonblocking semantics, I see no reason for ping to request nonblocking
I/O for something that has always been nonblocking already.  It would
mean, basically, forking a NetBSD-specific branch of ping's source to
cope with NetBSD's breaking a very long-standing aspect of IP sockets.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B