Date: Thu, 03 Dec 1998 16:11:33 -0800 From: Mike Smith <mike@smith.net.au> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-current@FreeBSD.ORG Subject: Re: KLD - what's the idea? Message-ID: <199812040011.QAA01130@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 03 Dec 1998 10:57:15 EST." <199812031557.KAA27821@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> <<On Wed, 02 Dec 1998 17:45:34 -0800, Mike Smith <mike@smith.net.au> said: > > >> Cannot we unload all of the device recognition code once it has done its > >> job and reload it each time the PCCARD finds a new arrival? > > > What "device recognition code"? If we keep the current model, it's all > > in a user-space application. > > The current model is totally broken and doesn't work like anyone > else's PC-Card implementation anywhere. This Is Bad since it makes > drivers much harder to port than they need to be. I tend to agree that the current model isn't all it could be. > > If we were to move the CIS ID : driver/rules match code into the > > kernel, it would be so small and trivial that the effort involved in > > loading/unloading it would be disproportionate to the space regained > > (maybe 1 page). > > Under the new bus architecture (and also the standard Card Services > model), the correct thing is to let each candidate driver look at the > CIS and see whether it can handle the device -- for a simple driver, > probably about 100 bytes. To put this on a page by itself so that it > could be unloaded would waste most of a page. 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. Rather, the approach I've been slowly taking with the PnP code in the new bootblocks has been to produce a set of uniquely formatted ASCII identifiers, sorted by "match quality" for a device, and then have an external database which pairs identifiers with drivers and optional parameters. This means that you can add a new device for which an existing driver is adequate simply by updating the (flat text) database. By using several identifiers sorted by priority you can have class-specific drivers which can be overridden by device-specific drivers when appropriate. So for a PCCARD you have the first identifier being the manufacturer/ model/version set, eg. "Megahertz/XJ4336-CC4336/5.0" and then you can add a second identifier build from the functional ID and functional extensions - in the case of this modem you'd have something like "serial/16550/modem". Naturally the disposition of this database can be tweaked; at the moment it'll be moving to /boot/pnpdata, where it will be consulted -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199812040011.QAA01130>