Date: Tue, 13 May 1997 11:43:07 +0200 From: Stefan Esser <se@FreeBSD.ORG> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: dfr@nlsystems.com, current@FreeBSD.ORG Subject: Re: Backwards compatibiliy for isa_driver Message-ID: <19970513114307.17799@x14.mi.uni-koeln.de> In-Reply-To: <199705130146.LAA12203@genesis.atrad.adelaide.edu.au>; from Michael Smith on Tue, May 13, 1997 at 11:16:23AM %2B0930 References: <19970512220244.64858@x14.mi.uni-koeln.de> <199705130146.LAA12203@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On May 13, Michael Smith <msmith@atrad.adelaide.edu.au> wrote:
> Before you go any further with this, you should check with the
> Alpha people, and have a look at the NetBSD code for the
> same thing.
Yes, I'm willing to do that ...
> Whilst I found the documentation for the NetBSD approach to
> be pathetic (read: nonexistent), it was relatively easy to
> find enough examples to get something going.
> The NetBSD approach blurs the distinction between "bus" and
> "device", which I think is _the_ critical point. A nested
> bus is a "device" on its parent bus, but a "bus" to devices
> below it.
Yes, I fully agree. That's exactly what I was planning.
I have seperated the data into several data structures:
1) Structure common to all devices, values private per
device instance:
- Unit number
- Operational state
2) Structure depends on bus type, values private per
device instance, maintained by the "device" above,
which happens to be a "bus device":
- "wired position" (e.g. "at pci1 slot 4")
- probemessage()
- resources
3) Driver specific data structure, values private per
device instance:
- xxx_softc
4) Common data structure, values private per driver but
shared by all instances of this device type:
- drvname
- numunits
- maxunits
- probe()
- attach()
- shutdown()
Of course, the struct components are not meant to be a
complete list, just a few typical examples ...
> Hmm, Doug R. and I are just opening a discussion on a "resource manager"
> (someone just threw a PnP card at me, heh) which might well be relevant
> in this context.
I found a $15 PnP sound card, which I bought just for
playing with ISA PnP ... :)
My implementation of resource management uses the
following functions:
devdata *resource_check (unsigned type, unsigned flags,
addr_t low, addr_t high);
int resource_claim (devdata *dev, unsigned type, unsigned flags,
addr_t low, addr_t high);
void resource_free (devdata *dev);
The following resource types are currently defined:
#define REST_NONE 0x00
#define REST_MEM 0x01
#define REST_PORT 0x02
#define REST_INT 0x03
#define REST_DMA 0x04
#define REST_MAX 0x04
And these are the only valid "flags" values, currently:
#define RESF_NONE 0x00
#define RESF_SHARED 0x01
Simplified example:
if ((otherdev = resource_check(REST_IRQ, RESF_SHARED, irq, irq) != NULL)
{
printf("irq conflict with device: %s", devname(otherdev));
return -1;
}
The actual resource check can be either a function of the
"bus device" operating on data from section 2) above, or
(in my current implementation) is a common function, which
maintains its own resource database (and needs the function
resource_claim() to add resources to this database).
> There was mention of a NetBSD "extent allocator" which I need to follow
> through.
>
> Jason T., are you reading this? A few quick words in summary would
> be handy...
I'd be very interested in pointers to further information,
too ...
Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970513114307.17799>