libnl 3.2.8

[Thomas Graf]

On Wed, May 02, 2012 at 05:40:02PM -0600, Scott Bonar wrote:
> I'm having issues with this release, specifically around the fact
> that nl.c::nl_recvmsgs() now returns a positive number on successful
> reads indicating the number of messages that were actually recv'd.
> The issue is that I have run across several instances where the
> caller of nl.c::nl_recvmsgs() "assumes" that a return of 0 is a
> successful read instead of >0 and therefore does not take the same
> paths as 3.2.7.  A good example is that when I call
> link.c::rtnl_link_get_kernel() the code should wait for an ACK if an
> object is returned, but is does not because the return of
> nl.c::nl_pickup() is now >0 instead of 0.  Now we are out of
> order/sequence with our ACK packets and things go downhill from
> there.
> 
> There are probably other situations, but that was the one I tracked
> down.  What was the reason for this API change to nl_recvmsgs() and
> what will I break if I remove the nrecv counter in recvmsgs()?

The reason for this change was to allow for a caller to see whether
a message was parsed or not. This is extremely handy for sockets
in non-blocking mode.

I can see the fallout. I will revert to the old return values and
add a new function to provide the additional processing information.