From owner-freebsd-new-bus  Sat Mar 11  9:24:13 2000
Delivered-To: freebsd-new-bus@freebsd.org
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38])
	by hub.freebsd.org (Postfix) with ESMTP id 7579B37BC99
	for <new-bus@freebsd.org>; Sat, 11 Mar 2000 09:23:58 -0800 (PST)
	(envelope-from dfr@nlsystems.com)
Received: from nlsys.demon.co.uk ([158.152.125.33] helo=herring.nlsystems.com)
	by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
	id 12TpcK-0001Kc-0A; Sat, 11 Mar 2000 17:23:56 +0000
Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3])
	by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id RAA30462;
	Sat, 11 Mar 2000 17:30:31 GMT
	(envelope-from dfr@nlsystems.com)
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
In-Reply-To: <20000311114255.T68308@daemon.ninth-circle.org>
Message-ID: <Pine.BSF.4.21.0003111706270.79394-100000@salmon.nlsystems.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-new-bus@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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