Subject: Re: placement of PFIL_HOOKS filtering points
To: Jonathan Stone <jonathan@DSG.Stanford.EDU>
From: Darren Reed <email@example.com>
Date: 11/08/2000 23:05:38
In some email I received from Jonathan Stone, sie wrote:
> In message <200011072103.IAA06706@avalon.reed.wattle.id.au>Darren Reed writes
> >> SIGCOMM '96. a more complete description is at:
> >> http://www.pdos.lcs.mit.edu/~engler/dpf.html
> >That was something I tried to mention to you on icb, before you started
> >on this, Jason, and which you obviously ignored as you and Chris seemed
> >intent on "reinventing the wheel".
> >I'm not sure that DPF is what you want to do with BPF - typically a BPF
> >filter is "compiled" and put in place as a static filter for a program
> >such as dhcpd, rarpd, etc. DPF is more than just "covert opcodes into
> >machine code".
> Yeah, but the part of DPF which does "safe" dynamic generaton of
> native machine code for a give filter seems pretty applicable.
> That part is done, for mips and alpha.
> I think it'd be kewld to have a systemw hich generates native
> machine-codeto evaluate ipfil rules, too :).
4.0alpha16 has ipf -> c-code conversion in it. Can compile into the
kernel or load as the LKM as non-flushable rules.