[Dnsmasq-discuss] NETLINK_NO_ENOBUFS not defined on old platforms

[Simon Kelley]

On 20/03/2020 02:18, Roy Marples wrote:
> On 19/03/2020 22:01, Simon Kelley wrote:
>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=0506a5ed4e56863627c54aedad30ad61221292ef
>>
>>
>>
>> should handle both old kernel header files and old kernels, in any
>> combination.
> 
> I really dislike this approach because it makes the assumption that no
> other symbol will take No 5.

Linux is pretty hot on ABI backwards compatibilty, so I doubt that there
has been any other netlink sockopt with number 5 in the past, or if that
sockopt disappears in the future any other opt would re-use it. Anyone
adding sockopts to a private kernel and picks the next free number,
rather than one at the end of the range or a defined private space needs
their bumps felt: it's obvious that it's going to clash with the
mainline kernel. I could #ifdef all the code if NETLINK_NO_ENOBUFS isn't
defined, and that would only lose us the ability to build against old
headers and still get the fix on a new enough kernel. It's probably not
a big loss, but it addresses a problem that seems unlikely.

Note that the code checks the kernel version, so if you build on old
headers and run on an old kernel, then despite the code assuming sockopt
5, it won't call setsockopt(5) when running on the old kernel.


This code is Linux-only, so what BSD does doesn't count.

Simon.


> 
> Whilst this might be true for generic linux, is it true for customised
> linux?
> Or to put it another way I can point to many examples cross BSD where
> the ioctls differ in number but not name.
> 
> You might take the view "So what? We just support generic linux.".
> 
> I have started to take the hard stance with Arch Linux which shipped
> latest kernel headers and support that on an old LTS kernel. It's not
> maintainable because I've had 3 instances where dhcpcd used to do this
> and then promptly crashed on newer kernels because they had customised
> headers.
> 
> Modern software should not need this hack. Either #ifdef around it or
> require userland headers to define it. Don't hardcode it as it's not
> userlands responsibility to do it.
> 
> See the similar case where OpenBSD removed a ioctl but let it in the
> header - even worse!!
> 
> Roy
>