From owner-freebsd-arch@FreeBSD.ORG  Wed Nov  5 21:30:29 2003
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 7E25616A4CE; Wed,  5 Nov 2003 21:30:29 -0800 (PST)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id F14D04400B; Wed,  5 Nov 2003 21:30:26 -0800 (PST)
	(envelope-from bde@zeta.org.au)
Received: from gamplex.bde.org (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3p2/8.8.7) with ESMTP id QAA12100;
	Thu, 6 Nov 2003 16:30:23 +1100
Date: Thu, 6 Nov 2003 16:30:22 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Brian Fundakowski Feldman <green@freebsd.org>
In-Reply-To: <200311051925.hA5JPT6S003092@green.bikeshed.org>
Message-ID: <20031106160854.H6157@gamplex.bde.org>
References: <200311051925.hA5JPT6S003092@green.bikeshed.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: arch@freebsd.org
cc: fenner@freebsd.org
Subject: Re: bpf/pcap are weird
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Nov 2003 05:30:29 -0000

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