>PF_PACKET was originally architected by people who, at the time, were
>targeting ARCnet, or 10Mbit Ethernet for "high-end".  Copying all
>packets to userspace was deemd acceptable since allegedly "everybody"
>(i.e., even an old 486) could keep up.  Even then, early deployment of
>100Mbit Ethernet showed that PF_PACKET was a poor design for purposes
>like tcpdump; gigabit and 10Gbit Ethernet makes it look pretty silly.

if PF_PACKET was a read-only interface, it might make some sense, even
though it would probably not be able to keep up with the actual
network traffic.  for PF_PACKET to handle writing packets out, would
it not have to be bound to some interface, or is it simply expected to
spray said packet out on all configured interfaces?

>>It's worth noting that an advantage of PF_PACKET vs. bpf(4) is that
>>a PF_PACKET socket may be bound to an ethertype (or 802.3 frame)
>>and can receive these frames on any interface if desired (analogous
>>to a raw IP socket).  IIRC, a bpf pseudodevice must be bound to an
>>interface to receive, thus requiring a bpf in the kernel for every
>>interface on which one wants to receive.
>
>I thought Jason Thorpe was making NetBSD's bpf into a cloning device?

pending work on devvp or some such, yes, i believe so.  but that was
to get around the requirement that you build support for "n" bpf
devices into your kernel at compile time, not in a manner that would
affect this.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."