Date: 09 Sep 2003 12:23:08 +0100 From: Doug Rabson <dfr@nlsystems.com> To: arch@freebsd.org Subject: When to burn those bridges Message-ID: <1063106587.25817.23.camel@builder02.qubesoft.com>
next in thread | raw e-mail | index | archive | help
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: <Intel 82557 Pro/100 Ethernet> 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: <DP83840 10/100 media interface> on fxp0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1063106587.25817.23.camel>