From owner-freebsd-arch@FreeBSD.ORG Thu Sep 2 08:06:20 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB2C916A4CE; Thu, 2 Sep 2004 08:06:20 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EB0843D5E; Thu, 2 Sep 2004 08:06:20 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i8284lrR090618; Thu, 2 Sep 2004 02:04:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 02 Sep 2004 02:05:00 -0600 (MDT) Message-Id: <20040902.020500.26961549.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: "M. Warner Losh" In-Reply-To: <20040902000637.GA4120@odin.ac.hmc.edu> References: <20040901193445.GC12483@odin.ac.hmc.edu> <41364415.9040708@elischer.org> <20040902000637.GA4120@odin.ac.hmc.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@freebsd.org cc: julian@elischer.org cc: julian@freebsd.FreeBSD.ORG Subject: Re: if_data size issues X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2004 08:06:20 -0000 In message: <20040902000637.GA4120@odin.ac.hmc.edu> Brooks Davis writes: : - After 5.3 is released, declare that upgrades to 6.0 from releases : other then 4.x (x>=11) and 5.y (y>=3) require special handling and : allow if_data to grow as demand requires. There have long been plans to remove support to upgrade to 6.0 from 4.x, and I plan on moving forward with those plans after the 5.3 branch. There are a large number of hacks in place to allow upgrading all the way back to the 4.0 branch point, and these hacks have been the source of a lot of frustration and gnashing of teeth over the years. By right of conquest (eg writing the legacy library and working with both sides of this issue for litterally years), and by general consensus of the folks that do the grunt work to make it possible to upgrade, I think that desupporting upgrade to 6.0 from anything less than 5.2 (or maybe 5.1 for a time) is a reasonable path to follow. Given that the rest of the build system support for upgrades will be limited, I'm not sure the benefit of supporting the upgrade from 4.11 to 6. We never really supported upgrading from 3.5.1 to 5.0-Release, for example. Warner