tcpdump mailing list archives
Re: NetBSD CI breakage
From: Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Wed, 13 Jul 2022 23:16:18 -0700
--- Begin Message --- From: Guy Harris <gharris () sonic net>
Date: Wed, 13 Jul 2022 23:16:18 -0700
On Jul 10, 2022, at 2:48 PM, Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:The last CI build of the libpcap-1.10 branch failed on netbsd-aarch64 because the latter now uses GCC 12. Commit 4e7f6e8 makes a lazy fix for that in the master branch; if a more sophisticated solution is not required,I changed it to a slightly different fix. The problem was that, on platforms without a cloning BPF device, the BPF device open code iterates over BPF device names, and the loop index was a signed integer, so, in theory, if you have 2^31 BPF devices, from /dev/bpf0 to /dev/bpf2147483647 open, the loop index will go from 2147483647 to -2147483648, and, while 2147483647 requires 10 characters, -2147483648 requires 11. Thus, the length of the buffer had to be increased. I changed the index to an unsigned integer, so it goes from 0 to 4294967295, all of which require 10 characters. On most OS versions without a cloning BPF device, you're unlikely to have 2^32 BPF devices (almost certainly not on an ILP32 platform, for obvious reasons!), or even 2^31 BPF devices, so, in practice, this won't be a problem. The only OS I know of that 1) has no cloning BPF device and 2) auto-creates BPF devices if you try to open one that's past the maximum unit number (it's named after a British naturalist and evolutionist whose last name is not "Huxley" :-)). It uses "bpf%d" to generate the device names, so it could, in principle, create a device named /dev/bpf-2147483648, but the default upper limit on the number of BPF devices is 256, so you'd have to sysctl it up to a value above 2^31 (the sysctl value is unsigned, so you can do it; that also means that "bpf%d" should be "bpf%u", so it's time to file a Radar^WFeedback on that).a simple cherry-pick into libpcap-1.10 should be sufficient to pass CI again.I've backported a bunch of changes to 1.10, including your change and mine for that; the netbsd-aarch64 build now seems to be working for libpcap-1.10. (Or should that be netbsd-a64, or netbsd-arm64? Thanks, Arm, for making "architecture" names so complicated....)
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- NetBSD CI breakage Denis Ovsienko via tcpdump-workers (Jul 10)
- Re: NetBSD CI breakage Guy Harris via tcpdump-workers (Jul 13)
- Message not available
- Re: NetBSD CI breakage Denis Ovsienko via tcpdump-workers (Jul 14)