When to burn those bridges
From: Doug Rabson (dfr_at_nlsystems.com)
Date: 09/09/03
- Previous message: David Taylor: "Re: config files in packages (Re: (proposal) new flag forpkg_delete)"
- Next in thread: M. Warner Losh: "Re: When to burn those bridges"
- Reply: M. Warner Losh: "Re: When to burn those bridges"
- Reply: John Baldwin: "RE: When to burn those bridges"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
To: arch@freebsd.org Date: 09 Sep 2003 12:23:08 +0100
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
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
- Previous message: David Taylor: "Re: config files in packages (Re: (proposal) new flag forpkg_delete)"
- Next in thread: M. Warner Losh: "Re: When to burn those bridges"
- Reply: M. Warner Losh: "Re: When to burn those bridges"
- Reply: John Baldwin: "RE: When to burn those bridges"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
