On 09/10/08 18:46, Donour Sizemore wrote: > ... > > I would hardly call it a plan, but the idea is just to call BPF from > PF_PACKET when needed. I guess the question is, "What does BPF need to > know about PF_PACKET?" I don't know enough about bpf to answer that > question. Darren is probably in a better position to say anything than > I am. Building a general purpose filter API for kernel modules is > certainly beyond that scope of this proposal.
BPF doesn't need to know about PF_PACKET, it is PF_PACKET that needs to know about BPF. BUT, having said that, I'm not at all sure associating BPF with PF_PACKET is correct because an application that, today, uses PF_PACKET on Linux is using their own interpreted filter language, not BPF. So BPF may very well be the wrong choice here if we are concerned with Linux compatibility. Which is to say that if we wanted to use BPF and be compatible with BPF applications then we need to implement BPF independent of this project. That said, there are few applications that directly interface with BPF, most of them use libpcap and that uses whatever happens to be right for the given platform. Detection of PF_PACKET will, at present, not imply BPF but the Linux equivalent, to libpcap. Darren _______________________________________________ networking-discuss mailing list [email protected]
