From owner-freebsd-arch@FreeBSD.ORG Tue Sep 9 04:23:12 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 3D58916A4BF for ; Tue, 9 Sep 2003 04:23:12 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3C6143FBD for ; Tue, 9 Sep 2003 04:23:10 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h89BN9SO046342 for ; Tue, 9 Sep 2003 12:23:09 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h89BN8Tj094141 for ; Tue, 9 Sep 2003 12:23:09 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: arch@freebsd.org Content-Type: text/plain Message-Id: <1063106587.25817.23.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 09 Sep 2003 12:23:08 +0100 Content-Transfer-Encoding: 7bit Subject: 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: Tue, 09 Sep 2003 11:23:12 -0000 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? I have been working recently on some stuff which probably isn't appropriate for 5.x. I started trying to simplify the smbus driver so that you don't need three devices for each smbus and also to support kernel drivers for smbus-attached devices (e.g. sensors). This is possible using the current api but gets a bit clumsy in places. 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. 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? 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); If there was a way, for instance, of stating that a cardbus was a kind of pci, then the individual drivers can be simplified. The driver searching system could easily be extended to search for drivers in base classes of the bus driver. The same technique could be used to reduce the number of 'converter' devices. Right now, every network device has a child miibus device that manages the attached phys. Using multiple inheritance, the network drivers would be able to derive from the miibus device instead, giving a simpler device structure which more closely matches the real hardware, e.g.: fxp0: port 0x18c0-0x18df mem 0xe8000000-0xe80fffff,0xe8105000-0xe8105fff irq 10 at device 9.0 on pci0 fxp0: Ethernet address 1:2:3:4:5:6 nsphy0: on fxp0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto