Date: Sat, 11 Mar 2000 13:07:31 -0700 From: Warner Losh <imp@village.org> To: Doug Rabson <dfr@nlsystems.com> Cc: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl>, new-bus@FreeBSD.ORG Subject: Re: Abstraction API for drivers Message-ID: <200003112007.NAA27217@harmony.village.org> In-Reply-To: Your message of "Sat, 11 Mar 2000 17:26:06 GMT." <Pine.BSF.4.21.0003111706270.79394-100000@salmon.nlsystems.com> References: <Pine.BSF.4.21.0003111706270.79394-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.4.21.0003111706270.79394-100000@salmon.nlsystems.com> Doug Rabson writes: : Drivers would call a generic PnP matching routine which would allow : 'plugins' to match specific kinds of PnP ID, e.g. eisa, pci, usb etc. pccard, cardbus should be added to the list. PCCARD and Cardbus is a more complex example. In pccard devices, there's an area of ram called this cis. The cis has a number of different things in it that can be used to identify a card. There are the familiar manufacturer and model strings, but also there's a manufacturer numeric ID (assigned by the pcmcia consortium), a numeric model number (assigned by the manufacturer), a notion of a function type (similar, but more restricted than, the pci device class) as well as some other card/function specific information needed by the driver (the ethernet address springs to mind for nic cards). I'm not sure how you'd encapsulate all this into a generic mechanism. Some drivers will match to a functional type of card (eg sio will match all modem/serial cards). Some drivers will want to match against the numeric IDs. Some will match against CIS strings. Some (the ed driver) will likely need to match against all of these things since some of the supported cards have CIS but no numeric ids, etc. I'm not sure how a generic scheme would fit into this morass of conflicting standards. Maybe each PnP bus needs to have a bus function that would take void * and match against the values, if present, for that card. bus_match_pnp_id(device_t bus, device_t child, int type, void *value) where type is an enum (or string) of some sort (likely string would be better for binary compatibility over the long haul). You could then write bus generic routines to do the matching based on the different types of information available. The bus' specific matching routine(s) should use the bus_match_pnp_id interface. What makes this messy is that you don't have a single ID that says yes or not, but rather a collection of them to match. It would be hard to come up with a good syntax for "smashing" the multiple ones into a single ID for pccard. For the numberic fields, this is easy (put mfg part in one word, and model part in the other word and use the agregate). For strings in PCCARD land, this is hard because the string can and does often contain any character at all. A quick survey shows that they match the following regular expression: [-A-Za-z0-9/.()+*]+ so you'd have to take the chance that there'd be no oddballs of a certain type like one of `~|\ and then use that as a separator. I think that I've seen ':' be used in CIS strings, but there are no entries in pccard.conf.sample right now that use it. Will have to look in the standard. Maybe the right thing to do is just use the numeric ones for pccard/cardbus and let those drivers that need to fall back to CIS matching to do so with a mechanism outside of this. The CIS strings aren't PnP identifiers after all, but are being abused as such with the current system. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003112007.NAA27217>