Mikael Karpberg wrote: > According to Mike Smith: > > This is actually a major defect in the newconfig design; if the kernel > > doesn't already know about a device when it is built, it can never > > support it. > > That would be so lovely, with a DEVFS too: > > Plug your Cool card into your pcmcia slot, and get the message on > the sytem console that an unknown pcmcia card called "Cool", made > by CoolMakers, Inc. Damn... not even a generic driver wanted this card. > Pull the card out and go for the web: > > # ftp ftp.a.cool.thing.com > ftp> get cool.tgz > --> Downloading file. > ftp> quit > --> Good bye. > # install_driver cool.tgz > --> Adding driver to driver database, and installing /modules/cool.ko! > > And at this point the kernel has not loaded the driver, but just > been told there's a new driver around and for what cards and vendors > it works, etc. This is done by a library call, or something, which > does adds the driver to the database, and a syscall to update the > kernel's already loaded database, or to get it to reload the database. > > Plug the card in again, and the kernel loads in cool.ko and probes the > card, and created a /dev/cool, and everything works just fine. No reboot, > no recompile, nada. *purr*
This is exactly the way new-bus works. You merely load the driver, and the configuration engine reruns the probe for unclaimed devices on smart busses automatically. Of course, kicking off a generic driver when a more specific driver is loaded is a different problem... I have not looked to see if this is supported. It should not be a significant problem if it is not yet implemented. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
