On Wed, Nov 08, 2000 at 12:33:25AM +1100, Darren Reed wrote:

 > For this one specific application you're building, jason, how many
 > other applications are you going to effect ?

Regarding IP_HDRINCL -- we've been talking about fixing (well, changing)
for a long time.  Check the tech-net archives from ... 2 years ago?

 > Since you seem to be the only one needing the fields in network order,
 > shouldn't you be using a wrapper which does the byte swapping for you?
 > 
 > At least that way you fix your "ip_output.c" problem too.

Sure, mine could use a wrapper, and that's what I initially did.  But
then I added the filtering points in the bridging code.  And, lo and
behold, in order to filter there, I would have had to parse the Ethertype
and all that other nonsense to find the IP header fields to swap -- but
I didn't want to filter just IP!  I want to filter IPv6, Appletalk, and
various Ethernet-level protocols.

At some point, this breaks down :-)

So, when I looked back at this history of PFIL_HOOKS, I remembered that
it was basically added specifically to support IP Filter (HI DARREN! :-)
at the time, in the same place as your stock patch to ip_input().  So,
really, the current scheme is actually tailored to your application,
and not truly generic as the whole idea of PFIL_HOOKS was intended (which
is why we don't have the fr_checkp type patch that you ship with IP Filter).

Look, I'm not proposing to screw over your application.  I've already
written the necessary wrappers for IP Filter (because I'm currently
using that, too!)  I just want to make the PFIL_HOOKS mechanism truly
generic so that more protocols and filter engines can really use it.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>