Date: Mon, 3 Nov 2008 12:47:02 -0500 From: John Baldwin <john@baldwin.cx> To: Warner Losh <imp@freebsd.org> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: 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... Message-ID: <200811031247.02826.john@baldwin.cx> In-Reply-To: <200811020256.mA22uG1i026765@svn.freebsd.org> References: <200811020256.mA22uG1i026765@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200811031247.02826.john>