From owner-freebsd-current  Tue May 13 02:44:11 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id CAA12280
          for current-outgoing; Tue, 13 May 1997 02:44:11 -0700 (PDT)
Received: from Sisyphos.MI.Uni-Koeln.DE (Sisyphos.MI.Uni-Koeln.DE [134.95.212.10])
          by hub.freebsd.org (8.8.5/8.8.5) with SMTP id CAA12272
          for <current@freebsd.org>; Tue, 13 May 1997 02:44:06 -0700 (PDT)
Received: from x14.mi.uni-koeln.de (annexr2-45.slip.Uni-Koeln.DE) by Sisyphos.MI.Uni-Koeln.DE with SMTP id AA22894
  (5.67b/IDA-1.5 for <current@freebsd.org>); Tue, 13 May 1997 11:43:47 +0200
Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.5/8.6.9) id LAA13748; Tue, 13 May 1997 11:43:08 +0200 (CEST)
Message-Id: <19970513114307.17799@x14.mi.uni-koeln.de>
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
References: <19970512220244.64858@x14.mi.uni-koeln.de> <199705130146.LAA12203@genesis.atrad.adelaide.edu.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.68
In-Reply-To: <199705130146.LAA12203@genesis.atrad.adelaide.edu.au>; from Michael Smith on Tue, May 13, 1997 at 11:16:23AM +0930
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

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