Date: Tue, 09 Sep 2003 19:03:35 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: dfr@nlsystems.com Cc: arch@freebsd.org Subject: Re: When to burn those bridges Message-ID: <20030909.190335.130622954.imp@bsdimp.com> In-Reply-To: <1063106587.25817.23.camel@builder02.qubesoft.com> References: <1063106587.25817.23.camel@builder02.qubesoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <1063106587.25817.23.camel@builder02.qubesoft.com>
Doug Rabson <dfr@nlsystems.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030909.190335.130622954.imp>