Skip site navigation (1)Skip section navigation (2)
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>