Re: New preview patch for ipfw to pfil_hooks conversion

From: Luigi Rizzo (rizzo_at_icir.org)
Date: 06/22/04

  • Next message: Angelo Turetta: "Re: New preview patch for ipfw to pfil_hooks conversion" 
    Date: Tue, 22 Jun 2004 02:50:54 -0700
To: Andre Oppermann <andre@freebsd.org>

    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
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"

  • Next message: Angelo Turetta: "Re: New preview patch for ipfw to pfil_hooks conversion"