From owner-cvs-all  Fri Sep 18 18:21:12 1998
Return-Path: <owner-cvs-all>
Received: (from daemon@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id SAA19330
          for cvs-all-outgoing; Fri, 18 Sep 1998 18:21:12 -0700 (PDT)
          (envelope-from owner-cvs-all)
Received: from time.cdrom.com (time.cdrom.com [204.216.27.226])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA19307;
          Fri, 18 Sep 1998 18:21:00 -0700 (PDT)
          (envelope-from jkh@time.cdrom.com)
Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1])
	by time.cdrom.com (8.8.8/8.8.8) with ESMTP id SAA04215;
	Fri, 18 Sep 1998 18:20:55 -0700 (PDT)
	(envelope-from jkh@time.cdrom.com)
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: nash@mcs.net (Alex Nash), eivind@yes.no, cvs-committers@FreeBSD.ORG,
        cvs-all@FreeBSD.ORG
Subject: Re: cvs commit: src/sbin/ipfw ipfw.c src/sys/conf files src/sys/i386/isa if_ed.c if_ep.c if_lnc.c src/sys/net if_ethersubr.c srcOR 
In-reply-to: Your message of "Fri, 18 Sep 1998 21:24:12 +0200."
             <199809181924.VAA26938@labinfo.iet.unipi.it> 
Date: Fri, 18 Sep 1998 18:20:55 -0700
Message-ID: <4211.906168055@time.cdrom.com>
From: "Jordan K. Hubbard" <jkh@time.cdrom.com>
Sender: owner-cvs-all@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> Size constraints are a sad fact of life and it is difficult to get
> things right. The reason i reduced FW_IFNLEN was to fit the struct
> ipfw within an mbuf. Changin IFNAMSIZ might break some things i
> don't have control upon, and certainly would require recompiling
> many more binaries because the dependency between machine limits
> is not always explicit or checked in include files (e.g. the MH_LEN
> vs IFNAMSIZ).
> 
> i can put FW_IFNLEN back to IFNAMSIZ, but then we lose the
> SKIPTO optimization and dummynet because we lose 8 bytes
> on each union ip_fw_if (6 bytes for the name, 2 for alignement) and
> the additional 16 bytes will bring the struct ipfw to 112 bytes.
> 
> Frankly i don't see an evident advantage, given that my change cannot
> break functionality but just binary compatibility for a single program.

Just to jump in here - yes, Garrett and I reviewed Luigi's fix so
please don't shoot him.  He should have noted this in the reviewed by
field and for that you can give him a small smack on the hand, but
he did at least HAVE it reviewed first. :)

And yes, the issues with ipfw should be also noted in the release
notes for 2.2.  I'll let Luigi do the honors since that all goes hand
in hand with being a committer. :-)

- Jordan