Date: Fri, 18 Sep 1998 21:24:12 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: nash@mcs.net (Alex Nash) Cc: 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 Message-ID: <199809181924.VAA26938@labinfo.iet.unipi.it> In-Reply-To: <19980918133656.A6449@Mcs.Net> from "Alex Nash" at Sep 18, 98 01:36:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. (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. 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. cheers luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809181924.VAA26938>