Date: 10 Sep 2003 09:07:44 +0100 From: Doug Rabson <dfr@nlsystems.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: arch@freebsd.org Subject: Re: When to burn those bridges Message-ID: <1063181264.43759.6.camel@herring.nlsystems.com> In-Reply-To: <20030909.190335.130622954.imp@bsdimp.com> References: <1063106587.25817.23.camel@builder02.qubesoft.com> <20030909.190335.130622954.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2003-09-10 at 02:03, M. Warner Losh wrote: > 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. If I commit this work to -current now, it will break ABI compatibility with 5.1-RELEASE. When is the ABI for 5.x suppose to be frozen? Does it matter if I break the 5.1 ABI in current? For what its worth, this change will also make the kobj method dispatch SMP safe (without locks). > > : 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. Drivers which really need something special for cardbus will be able to override things by defining a subclass of their pci driver which is listed in the cardbus devclass. > > : 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. Its mainly a cosmetic thing but it has always been an irritation to me to have these little clusters of devices where there is only one piece of hardware, e.g.: hostb0 pci0 pcib1 pci1 amdpm0 smbus0 smb0 should become: pci0 pci1 amdpm0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1063181264.43759.6.camel>