Date: Sat, 5 Dec 1998 11:50:39 -0000 From: Paul Richards <paul@originative.co.uk> To: "'Mike Smith'" <mike@smith.net.au>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-current@FreeBSD.ORG Subject: RE: KLD - what's the idea? Message-ID: <E40CBF0361C7D111914000C0F0303D108819@OCTOPUS>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Mike Smith [mailto:mike@smith.net.au] > Sent: Saturday, December 05, 1998 12:08 AM > To: Garrett Wollman > Cc: Mike Smith; freebsd-current@FreeBSD.ORG > Subject: Re: KLD - what's the idea? > > > > <<On Thu, 03 Dec 1998 16:11:33 -0800, Mike Smith > <mike@smith.net.au> said: > > > > > I'm not fond of this sort of 'active match' approach at all; > > > particularly for pccard devices it makes it impossible to apply an > > > existing driver to a new peripheral without patching and > rebuilding the > > > driver, which is extremely lame. > > > > The driver needs to know what sort of bus it's on -- > there's simply no > > escaping that. > > I don't see anywhere I've even considered suggesting this. The point > I'm trying to make is that the match process needs to be run by the > *bus* code - it has access to the list of drivers attached to it as > well as to the results of it's PnP probes, and is the only > module in a > position to match the two together. > > The correct way to do this is to have a set of bindings between PnP > identifiers and driver names. Embedding this information in > the driver > is IMO wrong, simply because updating a driver is difficult while > updating a text file is easy. > I agree with this basic idea, I was starting to think along these lines when I was looking at the way the pci drivers are probed. If the table is generic enough we could use it for all hardware that can be identified by obtaining a signature and if the entry in the table is signature:entry point then we end up with a totally different way of looking at hardware probing that's actually a lot more powerful than we have now yet also simplifies the drivers since they don't need any bus specific probe code. You'd only need code for identifying and scanning each bus to obtain the bus specific hardware signatures and then you'd jump to the entry point. This can either be a card specific probe routine (for identifying revisions/clones/whatever) or doing something else entirely, possibly a null op for some hardware or something much more complicated e.g. if the signature represents another bus it can call the bus scan routine for that bus. The table doesn't even have to be static either, you could have loadable device drivers register their signature:entry point in a dynamic table (link it to a file for persistency if needed) so that you can add new drivers to your system on the fly but have the system updated so it's aware of the new hardware next time it boots. Management of device driver loading becomes an administration issue, if a piece of hardware/driver is causing you problems you can deregister the entry point from the table so it doesn't cause problems on next boot. Some of this duplicates what can be done with the boot time configuration tools but I think it's a more orthogonal solution to the whole issue of managing devices and drivers. With not too much more work you could make this mechanism work for all hardware, for pci and other buses that you can safely probe for hardware id's you only have to write the bus scan routines but there's no reason why we couldn't modify the hardware probe phase to do the probing of other devices from a generic mechanism rather than from within the actual drivers. We already sort of do this with drivers having pci specfic probe routines that are maintained as part of the pci probe code rather than with the drivers. This doesn't have to replace the existing driver probe routines, they can be actually called as the entry point and they can do the same checks as they currenty do if that seems prudent but it does avoid the need to call every driver for every id to see if that driver wants to accept the hardware. It also provides a mechanism for supporting multiple drivers for the same hardware and be able to determine which driver is used by changing the table rather than the kernel config (possibly mute point with loadable drivers). If need be there could still be a catchall stage at the end of the boot process that calls all the probe routines for hardware that is still not allocated to a driver. This would still be a win overall even if this still happened since you'd only call all the probe routines for a few rogue pieces of hardware that weren't known in the table rather than for every piece of hardware in the machine and you could update the table the first time this happens so that next time it has a driver allocated or is flagged as not being supported. On the other hand, you might not want to do this and just have it reported as an unsupported piece of hardware. Food for thought..... Paul Richards Ph.D. Originative Solutions Ltd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E40CBF0361C7D111914000C0F0303D108819>