From owner-freebsd-current Thu Dec 3 16:13:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA19026 for freebsd-current-outgoing; Thu, 3 Dec 1998 16:13:45 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from dingo.cdrom.com (ppp5.portal.net.au [202.12.71.105]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA18990 for ; Thu, 3 Dec 1998 16:13:36 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id QAA01130; Thu, 3 Dec 1998 16:11:35 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812040011.QAA01130@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Garrett Wollman cc: freebsd-current@FreeBSD.ORG Subject: Re: KLD - what's the idea? In-reply-to: Your message of "Thu, 03 Dec 1998 10:57:15 EST." <199812031557.KAA27821@khavrinen.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 03 Dec 1998 16:11:33 -0800 From: Mike Smith Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > < 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