From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 18:03:46 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 0C8DA16A4BF for ; Tue, 9 Sep 2003 18:03:46 -0700 (PDT) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4BE543F3F for ; Tue, 9 Sep 2003 18:03:43 -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 h8A13aTX016833; Tue, 9 Sep 2003 19:03:42 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 09 Sep 2003 19:03:35 -0600 (MDT) Message-Id: <20030909.190335.130622954.imp@bsdimp.com> To: dfr@nlsystems.com From: "M. Warner Losh" In-Reply-To: <1063106587.25817.23.camel@builder02.qubesoft.com> References: <1063106587.25817.23.camel@builder02.qubesoft.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 01:03:46 -0000 In message: <1063106587.25817.23.camel@builder02.qubesoft.com> Doug Rabson writes: : I haven't been paying much attention recently on release engineering : issues so probably I have missed something. When do people think is the : right time to branch off the 5.x line of development and set fire to the : bridges? The plan was to remove them immediately after the branch to remove the support code. If nothing get fixed as we enter the "glide path" to 6.0-R, stuff that depened on the burned bridges gets killed. : This led me back to the idea of multiple inheritance in kobj/newbus. : Using multiple inheritance for the smbus re-work makes the chip drivers : much simpler since they don't have to explicitly list the 'parent' : methods in their method tables. The same thing goes for cardbus too. On : these lines, I went back and read through Justin's old inheritance : patches. These patches supported single inheritance for multiple : interfaces at the cost of changing the driver API considerably. I've : been tinkering with an alternative approach which supports multiple : inheritance at the class level, almost preserving the driver API while : changing the ABI slightly. I like this idea. : The only part of the API which is not preserved is the driver 'priv' : field which is only used for evil compatibility shim drivers. These : shims are currently stacked up on the post 5.x bonfire, hence the : question about when to light the fire. I would like to have a place to : commit my work-in-progress when it gets a little further - would it be a : useful idea to run a 6.x P4 tree for a while until the CVS tree : branches? You can do development of changes that depend on bridges burning in the 6.x tree. I'm sure that sledding will be really tough in current after the branch. The really big changes should be done in P4 and integrated into 6 when they are mature. 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. : It would also be nice to have some kind of inheritance tree for device : classes. Currently, drivers are grouped by devclass and the driver : matching election is done by iterating through the drivers listed in the : parent device's devclass. This means that many drivers have several : attachment declarations for different alternatives, e.g.: : : DRIVER_MODULE(fxp, pci, fxp_driver, fxp_devclass, 0, 0); : DRIVER_MODULE(fxp, cardbus, fxp_driver, fxp_devclass, 0, 0); Many cardbus drivers do nothing different. There are a few that do, but so long as it is possible to override things if they want it. : 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. Warner