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>