>>>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.
>
>I dont see that as a significant issue. Demux state (encoding what
>packets to deliver to a specific instance) and a queue (for
>as-yet-unread packets), is demux state and a queue, however you slice
>it.

if you have a queue, it will fill up.  if it's full, the kernel can't
queue more packets for you.  don't get me wrong...bpf also drops
packets if some queue is full.  but the queue does fill up.

PF_PACKET strikes me as something that is just "different" from pbf,
and probably possessing of its own quirks and foibles.  certainly just
opening one and reading from it would supply you with far too much
data and you'd need some sort of filtration mechanism.

>I thought Nick Amato's point was of PF_PACKET finessed exactly
>the config-time limit -- which Jason is doing away with.

not really, since PF_PACKET, as i understand it, provides one
interface to all network traffic, whereas with bpf, you'd have to bind
one to each interface you on which you wished to listen.  your code
would increase in compexity also, since you'd have to do polled io on
each bpf descriptor to read all the traffic in, instead of just
reading in the next packet.

-- 
|-----< "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."