OK, let me try again to explain what I'm trying to accomplish...  (I hope
that this isn't too boring for those without a MacOS background.)

NuBus(tm) cards come with an on-board ROM that includes MacOS device
drivers and associated data structures.  These device drivers have a well- 
documented interface.

The drivers and data structures are stored in the on-board ROM in a rather
obscure format.  The MacOS's SlotManager provides all the functionality
necessary to process this format.  And many (if not all) MacOS NuBus
drivers make subsequent calls to the SlotManager during their normal
course of operation to load new data structures.

The original color video LKM that Taras Ivanenko put together implemented
a minimal sub-set of the SlotManager.  But the implementation was not
complete, so many video cards (mine included) ended up not working since
they tried to make calls to un-implemented routines.

What I'm working on now is providing a _complete_ implementation of the
SlotManager.  Actually, that implementation already exists, in the MacOS
ROM.  Of the entire SlotManager, consisting of more than 60 major function
dispatch codes and numerous subroutines, only a handful have dependencies
on running in the MacOS environment.  In particular, the routines in
question make assumptions about the physical-to-virtual address mapping.
So, I'm setting things up to call the ROM-resident routines except for
these few exceptions.

This doesn't mean that we don't still need a NetBSD driver to support a
card.  On the contrary, we'll need such a driver to translate between
NetBSD I/O calls and MacOS calls.  Taras' original code included some of
this for the grf_mv (NuBus video card) driver;  in particular, he wrote
some additional IOCTL calls to handle things like switching into/out of
8-biut color mode.

So, we'll still need a NetBSD driver.  But instead of having to reverse-
engineer each and every card's hardware, and figuring out how to set the
right bits in the right registers at the right time, we'll be able to use
the card's ROM-resident driver.  All we need to do to support a new card
is to reverse-engineer the parameters that need to be passed to the 
higher-level interface that the ROM-resident driver, presumably a much
less difficult and time-consuming task.

And, since we're going to have a "native" NetBSD driver (native at least
from the interface that it provides to the user), it should fit into all
of the existing NetBSD constraints.  This includes making the driver code
responsible for mapping the NuBus card's address space into the kernel at
autoconfigure time.

Hence my dilemna - since the "in-between" driver code (ie, in between the
ROM-based driver code and the NetBSD driver API) is responsible for its
own mapping, but the generic SlotManager routines need to know what that
mapping is, I need to find some way of either finding a kernel VA that
corresponds to a given physical address or giving the driver some way to
pass that information back.

As for when I intend my SlotManager code to be called, I expect that its
initialization routine will be called only after all autoconfiguration of
the NuBus is complete.  The initialization code needs to create several
data structures that define the cards (the array of Slot Info records, the
lists of available Slot Resources, etc.)  And this initialization code
must be called before the NetBSD driver makes any calls to the SlotManager
routines.

Does this help? 

On Tue, 22 Jul 1997, Wolfgang Solfrank wrote:

> > 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
> 

-----------------------------------------------------------------------------
| Paul Goyette       | PGP Public Key fingerprint:  | E-mail addresses:     |
| Network Consultant |     0E 40 D2 FC 2A 13 74 A0  |  paul@whooppee.com    |
| and kernel hacker  |     E4 69 D5 BE 65 E4 56 C6  |  paul_goyette@ins.com |
-----------------------------------------------------------------------------