Re: New preview patch for ipfw to pfil_hooks conversion

From: Luigi Rizzo <rizzo_at_icir.org>
Date: Tue, 22 Jun 2004 02:50:54 -0700
On Mon, Jun 21, 2004 at 11:36:21PM +0200, Andre Oppermann wrote:
> Here is the next preview patch for the ipfw to pfil_hooks conversion:
> 
>   http://www.nrg4u.com/freebsd/ipfw-pfilhooks-and-more-20040621.diff
> 
> This patch significantly cleans up ip_input.c and ip_output.c.
> 

assorted comments:
- understood that this is WIP, but as someone else suggested it would
  be a lot better to split the patch in logical chunks and apply them
  one at a time. Especially because they seem to have different importance,
  e.g. (as far as i can tell):

  + ipfw pfil stuff
        i surely consider this extremely useful and welcome, but would
        prefer to put the hooks in ip_fw2.c instead of using a
        separate file -- both to keep ipfw stuff confined, and to
        use stricter compiler checks (e.g. define stuff static as
        much as possible, avoid exporting internal APIs, etc.)
        The only motivation against it would be if we plan to
        backport this stuff to 4.x where we still have the option
        of using ipfw1.

  + ip_reass replacement

  + ip options processing
        on this particular one i am a bit unsure -- what is the point
        for just moving stuff to a separate file instead of leaving
        it where it is (ip_input/ip_output) so that many functions
        that are only used there can be declared static as they are now ?
        I'd rather just apply bugfixes.

generally, i have become a big fan of very strict compiler checks -- lately
they have saved me a huge amount of time in identifying dead code,
inconsistent interfaces and other bugs, so when in doubt between two
alternatives i tend to privilege the one that gives more chances to
the compiler to check things.

>   o ipfw forward is not yet implemented again (comes next)
>   o ipfw layer2 is not yet implemented again (comes next)

of course it is fundamental to preserve the entire existing
functionality before the commit

cheers
luigi
Received on Tue Jun 22 2004 - 07:51:08 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:58 UTC