> Well, my intent here is to _not_ reinvent the wheel.  I'm implementing the
> slot manager interface so that other NetBSD/Mac68k device drivers can use
> the existing, on-board ROM-resident driver code and interface to it using
> a documented API - Apple's own driver calls to the Read, Write, Control,
> Prime, etc. entry points.
> 
> By taking this approach, I expect that the normal autoconfiguration
> process will occur, and the code in nubus.c will call all appropriate
> drivers to perform their own attach() calls.  Thus, I _assumed_ that the
> drivers themselves would be responsible for calling pmap_map(), as is
> currently the case with the video-board driver grf_mv.c (and presumably
> other nubus drivers, like the ones for Ethernet cards).  All I'm looking
> for is some way to find out what the driver code did (or didn't) do - is
> the physical address space for a given slot mapped, and therefore is there
> a driver for the card in that slot?

Hmm, I'm not sure that I understand your intentions correctly.  When is your
code intended to be called?  I was under the impression that it would be during
autoconfiguration as some last resort if there wasn't a native driver for some
card.  If this is indeed the case you cannot rely on the fact that some driver
would have already mapped some memory/device registers.  In fact, if some
driver would do this in its match routine and leave the area mapped, this
would be a bug.

If I'm babbling complete nonsense, please enligthen me on the intended
application of your code.

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800