Date: Fri, 18 Sep 1998 19:09:12 -0500 From: Alex Nash <nash@mcs.net> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: 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 Message-ID: <19980918190912.A16974@pr.mcs.net> In-Reply-To: <199809181924.VAA26938@labinfo.iet.unipi.it>; from Luigi Rizzo on Fri, Sep 18, 1998 at 09:24:12PM %2B0200 References: <19980918133656.A6449@Mcs.Net> <199809181924.VAA26938@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Sep 18, 1998 at 09:24:12PM +0200, Luigi Rizzo wrote:
> > Changing FW_IFNLEN to an arbitrary value was a step backwards. We were
> > already bitten by this once, and that's why it was set to IFNAMSIZ. If
> > you want to argue that 16 character interface names will never exist,
>
> i cannot say never, but for sure they don't exist now, so i'd try
> to deal with problems when we believe they are close to appear.
There are two problems:
- We can't be sure if any third party drivers have been written
with interface names dependent on IFNAMSIZ (indeed it was a
third party driver, the ET Frame Relay card, that prompted the
original change from 6 to IFNAMSIZ bytes).
- This dependency will be forgotten until *after* something breaks.
> (i even wonder if "config" is able to deal with 16-byte device
> names...)
:)
> > change IFNAMSIZ. Interface name length constraints don't belong in
> > ipfw.
>
> 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.
This is not necessary in -current, which is where I believe this code
should have gone instead of -stable.
> 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).
What's MH_LEN?
> 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.
I understand the constraints you were working within. I believe the
correct approach to the problem would have been to leave 2.2 alone and
bring DUMMYNET/BRIDGE into -current. The benefits being:
- No IFNAMSIZ issues.
- No breakage of ipfw in -stable, an historically problematic area
even when notifications are sent to the -stable mailing list.
- No bug risk to the -stable tree (I see a few fixes have already been
made).
> Frankly i don't see an evident advantage, given that my change cannot
> break functionality but just binary compatibility for a single program.
The change *can* break functionality (see above), although it is unlikely.
Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980918190912.A16974>