bpf/pcap are weird

[Bruce Evans]

On Wed, 5 Nov 2003, Brian Fundakowski Feldman wrote:

> Okay, this is goofy stuff and breaks a lot of code that otherwise makes
> certain assumptions about pcap/bpf that don't work on FreeBSD.  Our bpf(4)
> doesn't actually care about the non-blocking fd flag, and our pcap(3)
> doesn't care at all about BIOCIMMEDIATE.  Why do we have BIOCIMMEDIATE?  It
> seems like it's what SHOULD be implemented with the non-blocking I/O flag
> with the exception that if using O_NONBLOCK/FIONBIO you could actually query
> for the status, whereas you can't query for BIOCIMMEDIATE since it's only a
> SET and not a GET ioctl.

Er, FreeBSD's bpf certainly cares about the non-blocking fd flag.  It uses
it in bpfread() although not in any other device switch function:

		if (ioflag & IO_NDELAY) {
			BPFD_UNLOCK(d);
			return (EWOULDBLOCK);
		}

NetBSD still seems to use the old 4.4 code which ignores the non-blocking
fd flag in bpfread() and doesn't even use a dedicated non-blocking device
flag (it overloads the timeout).

bpfpoll() is reported to be broken; see PR 36219.  Rev.1.113 of bpf.c
may have disturbed this.  It removed the comment which said that
bpf_ready() doesn't acually imitate resultof(FIONREAD) != 0.

I don't know anything about BIOCIMMEDIATE.

Bruce