Date: Sat, 11 Mar 2000 17:26:06 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Jeroen Ruigrok/Asmodai <asmodai@wxs.nl> Cc: new-bus@freebsd.org Subject: Re: Abstraction API for drivers Message-ID: <Pine.BSF.4.21.0003111706270.79394-100000@salmon.nlsystems.com> In-Reply-To: <20000311114255.T68308@daemon.ninth-circle.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 11 Mar 2000, Jeroen Ruigrok/Asmodai wrote: > [Matthew, please feel free to correct me] > > Hi guys, > > after Matthew Dodd and me discussed some abstracting the access to the > newbus functionality with Poul-Henning Kamp. > > Basically what phk said was that we were repeating lots of code in our > PCI drivers. Matthew and me agreed on that aspect, but were concerned > about making the abstraction PCI only. If such an API would be created, > it should be a complete solution. > > Basically one of the things that will repeat itself a lot in PCI drivers > is: > > static int xl_probe(dev) > device_t dev; > { > struct xl_type *t; > > t = xl_devs; > > while(t->xl_name != NULL) { > if ((pci_get_vendor(dev) == t->xl_vid) && > (pci_get_device(dev) == t->xl_did)) { > device_set_desc(dev, t->xl_name); > return(0); > } > t++; > } > > return(ENXIO); > } > > In the probe case of a driver we will always have some sort of if > statement like the above excellent xl driver example. > > We will always pci_get_[vendor|device](dev) and comparing it to the > vendor/device id of the struct array of devices. > > After we find matches, we will always want to set the name with > device_set_desc(dev, name). > > In the case for PCI devices this will create a very repeatable piece of > code all along the drivers. > > Of course, given the total different way how, for example, ISA, EISA, > S-BUS, and such work this might provide some difficulty creating a > sufficient general API to allow for bus-independant abstraction. And > creating functionwrappers just for bus specific cases might be the only > solution, but if we can avoid it, it would be cool. =) > > Ideas, comments, suggestions? I was discussing this with Nick Hibma a while ago. I intend to improve this situation for the next generation of newbus. What I'm intending is to write a general system for PnP matching. The driver would register a table of PnP IDs and optional descriptions, possibly something like: struct pnp_match ids[] = { {"eisa:PNP0500", "Standard PC COM port"}, {"eisa:PNP0501", "16550A-compatible COM port"}, ... {0, 0} }; 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. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.21.0003111706270.79394-100000>