From owner-freebsd-arch@FreeBSD.ORG Wed Sep 10 08:31:38 2003 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 EEF0D16A4BF for ; Wed, 10 Sep 2003 08:31:38 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2CDB43FEC for ; Wed, 10 Sep 2003 08:31:36 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9/8.12.3) with ESMTP id h8AFVYTX022798; Wed, 10 Sep 2003 09:31:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 10 Sep 2003 09:31:34 -0600 (MDT) Message-Id: <20030910.093134.112624676.imp@bsdimp.com> To: dfr@nlsystems.com From: "M. Warner Losh" In-Reply-To: <1063181264.43759.6.camel@herring.nlsystems.com> References: <1063106587.25817.23.camel@builder02.qubesoft.com> <20030909.190335.130622954.imp@bsdimp.com> <1063181264.43759.6.camel@herring.nlsystems.com> X-Mailer: Mew version 2.2 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 Subject: Re: When to burn those bridges 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: Wed, 10 Sep 2003 15:31:39 -0000 In message: <1063181264.43759.6.camel@herring.nlsystems.com> Doug Rabson writes: : On Wed, 2003-09-10 at 02:03, M. Warner Losh wrote: : > If there's a really compelling reason (and this would be it), we can : > burn some bridges early. I wouldn't hold up your development based on : > these bridges being in harm's way. Others in the BSDcon terminal room : > are saying "do it now, screw waiting for 6". If you can get it done : > and solid, I'd do it before the branch. The drivers in harm's way : > either have out of tree replacements, or aren't that important, or : > need to be redone and this is a good excuse. : : If I commit this work to -current now, it will break ABI compatibility : with 5.1-RELEASE. When is the ABI for 5.x suppose to be frozen? Does it : matter if I break the 5.1 ABI in current? For what its worth, this : change will also make the kobj method dispatch SMP safe (without locks). We can still break ABI with 5.1 if there's a good reason. Making things MP stafe is a good reason. : > : The same technique could be used to reduce the number of 'converter' : > : devices. : > : > I like this. pcic/cbb have similar issues, but the size of the : > problem is small. : : Its mainly a cosmetic thing but it has always been an irritation to me : to have these little clusters of devices where there is only one piece : of hardware, e.g.: : : hostb0 : pci0 : pcib1 : pci1 : amdpm0 : smbus0 : smb0 : : should become: : : pci0 : pci1 : amdpm0 Actually, the bridges do add value, so at least pcib would need to remain. I think it would be hard to get rid of them, but there could easily be something that I'm missing. Warner