svn commit: r184549 - in user/imp/newcard/sys: dev/aic7xxx dev/ath dev/dc dev/firewire dev/fxp dev/if_ndis dev/ipw dev/malo dev/puc dev/ral dev/re dev/sio dev/sound/pci dev/uart dev/usb dev/vge dev...

[John Baldwin]

On Saturday 01 November 2008 10:56:16 pm Warner Losh wrote:
> Author: imp
> Date: Sun Nov  2 02:56:16 2008
> New Revision: 184549
> URL: http://svn.freebsd.org/changeset/base/184549
> 
> Log:
>   MFp4(newcard): remove explicit cardbus driver attachments.
>   
>   Since the pci/cardbus refactor, these have been unnecessary.  Well,
>   almost unnecessary.  There's a bug somewhere in subr_bus.c that
>   prevents kldload from working entirely correctly.  Remove them from my
>   tree in the hopes I'll fix that bug.

The problem is that in device_probe_child() we only use the drivers attached 
to the devclass of the bus device.  Probably what you would need to change 
would be to make a 'devclass_probe_child()' that takes a devclass and tries 
all the drivers for that devclass (basically, the first for-loop in 
device_probe_child()).  Then I would change device_probe_child() to try any 
base devclasses the driver inherits from.  You can find these in 
the "baseclasses" array in the 'driver_t' object.

However, there are several edge cases to consider.  For example, do you only 
try the "base" devclasses if none of the drivers in the main devclass match?  
Or do you do always do a full walk of all the devclasses to find the best 
driver?  That is, suppose I have a driver hung off of "cardbus" that returns 
BUS_PROBE_GENERIC and a driver hung off of "pci" that returns 
BUS_PROBE_DEFAULT?  I think I'd actually be inclined to prefer the "cardbus" 
driver.  Thus, I would do one pass of the 'main' devclass and only walk 
the 'baseclasses' if I didn't get a matching device.  For the walk of the 
baseclasses the same question applies.  For that I'm less sure, though it is 
probably easier to implement a strategy where you stop the first time you 
find a devclass with a matching driver.

-- 
John Baldwin