Date: Thu, 6 Nov 2003 16:30:22 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Brian Fundakowski Feldman <green@freebsd.org> Cc: fenner@freebsd.org Subject: Re: bpf/pcap are weird Message-ID: <20031106160854.H6157@gamplex.bde.org> In-Reply-To: <200311051925.hA5JPT6S003092@green.bikeshed.org> References: <200311051925.hA5JPT6S003092@green.bikeshed.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031106160854.H6157>