On Wed, 6 Nov 1996 17:22:42 +1100 (EST) 
 Andrew Cassin <acas@catt.rmit.edu.au> wrote:

 > Yes I grabbed the OpenBSD PnP support (which as you say was a port of
 > your code) and tried to port it to netbsd, but it needs <sys/extent.h>
 > and various functions which seem to be missing (find_emap() from memory??)

NetBSD does indeed have a <sys/extent.h>, but it is significantly different
from the OpenBSD "extent" code.

Also, the OpenBSD PnP code makes some bad assumptions, such as there
being only one "irq space", only one "i/o space", etc.

There are a few things I would definitely do different in a PnP world...

	- The per-bus isa_softc should keep it's own resource map
	  of irqs and drqs.  Depending on how interrupts are triggered,
	  irqs may be shared, so this should probably be an array of
	  ints (which hold some value indicating "free", or one
	  of the IST_* constants indicating the interrupt sharing
	  type already being used by that irq).  It's my understanding
	  that drqs can't be shared (please correct me if I'm wrong),
	  and there aren't that many of them, so this could be
	  a bitmask.

	- Four new ISA functions should be implemented:

		isa_io_alloc()
		isa_io_free()
		isa_mem_alloc()
		isa_mem_free()

	  They should take parameters similar to the eisa_mem_{alloc,free}()
	  functions, and do the obvious thing (obvious when you see
	  what eisa_mem_{alloc,free}() do :-).  Their implementations would
	  be machine-dependent because the extent maps used to implement
	  these functions are machine-specific.

	- A new bus type, "isapnp", should be created, which could
	  basically inherit all of the properties of the parent isa
	  bus.  Attachment of this "bus" should be deferred until all
	  other "regular" isa devices have been attached.  It's this
	  bus's job to initiate the (somewhat evil) PnP configuration
	  protocol, and attach all of the PnP devices (which are ignored
	  by the "isa" bus).  Each device would be responsible for
	  allocating resources on the "isapnp" bus, since they know
	  the constraints within they must work.

So, I guess, in my world, it'd look something like this:

mainbus0 at root
isa0 at mainbus0
[ stuff ]
isapnp0 at isa0
sb0 at isapnp0: [information about the soundblaster model]
sb0: using iobase [something] irq [something] drq [something]

...or something like that... I must admit I haven't thought about it
for a while.

Anyhow, just some random thoughts.

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939