Date: Fri, 04 Dec 1998 16:07:41 -0800 From: Mike Smith <mike@smith.net.au> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Mike Smith <mike@smith.net.au>, freebsd-current@FreeBSD.ORG Subject: Re: KLD - what's the idea? Message-ID: <199812050007.QAA00857@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 03 Dec 1998 21:46:14 EST." <199812040246.VAA00209@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> <<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 would be willing to have an > ``erratum database'' which indicates additional devices which should > be handled by an existing driver, but it should be the driver which > decides (after all, it might just inspect the programming model and > not look at the vendor information at all) whether it can handle the > card in question. The "programming model" is a secondary PnP identifier; see eg. the way that USB distinguishes between "device" and "class" identifiers - I made specific reference to this in my previous message. > (We need to have something like this anyway, since > the Linux Card Services manual indicates that some cards come with > completely bogus CIS.) As long as we can generate meaningful identifiers from the CIS, it doesn't really matter how bogus it is. Duplicating the bogosity-avoidance code in every device driver that has to deal with any PCCARD (in this case) would be poor technique. Better to implement it once. > In any case, the more like the official Card Services, the better, > since that's what will make it easy to port drivers. Which "official Card Services"? The "original" Card Services is terrible; it was designed for an environment with no autoconfiguration infrastructure. Foisting that on us will put us in the situation where PCCARDs and drivers are again "special cases". Needless to say, that would still be Bad. > > "serial/16550/modem". > > Ugh. I don't like the kernel being asked to parse more and more > arrays of text strings. Deal with data in their natural format. Given that text *is* the natural format for the source of the strings, this is silly. -- \\ 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?199812050007.QAA00857>