Date: Sun, 20 Sep 1998 23:28:14 -0700 From: Studded <Studded@dal.net> To: Alex Nash <nash@mcs.net> Cc: Luigi Rizzo <luigi@labinfo.iet.unipi.it>, 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: <3605F1FE.9590D52E@dal.net> References: <19980918133656.A6449@Mcs.Net> <199809181924.VAA26938@labinfo.iet.unipi.it> <19980918190912.A16974@pr.mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I feel strongly that these changes should be backed out of -Stable immediately. I spent several hours today trying to find why ipfw logging is broken, and I can't find the problem. I do think that what luigi's working on will add powerful functionality to freebsd eventually, but right now this shouldn't be in -Stable. This also an EXCELLENT example of why -Current should have been branched when the beta period for 3.0 started. Yes, this IS an "I told you so." For those that aren't following -Stable, I'm far from the only one who is having problems. There have been numerous complaints regarding NATD and other IPFW functions. Things should be put back the way they were before these changes were introduced into -Stable. Doug Alex Nash wrote: > > 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 -- *** Chief Operations Officer, DALnet IRC network *** "Yes, the president should resign. He has lied to the American people, time and time again, and betrayed their trust. He is no longer an effective leader. Since he has admitted guilt, there is no reason to put the American people through an impeachment. He will serve absolutely no purpose in finishing out his term; the only possible solution is for the president to save some dignity and resign." - William Jefferson Clinton, 1974
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3605F1FE.9590D52E>