> On Wed, 7 Apr 1999, Matthew Jacob wrote:
> 
> > On Wed, 7 Apr 1999, Jason Thorpe wrote:
> > 
> > > On Tue, 6 Apr 1999 18:41:29 -0700 (PDT) 
> > >  Matthew Jacob <mjacob@nas.nasa.gov> wrote:
> > > 
> > >  > So just to reconfirm- for sparc64 ports __sparc__ won't be defined, but
> > >  > __sparc64__ will be....
> > > 
> > > Note the lack of underscores in my message...
> > > 
> > > The kernel Makefiles define symbols that match $MACHINE, i.e. "sparc"
> > > and "sparc64".  Like "hp300", "amiga", "pmax", "mac68k", etc.
> > > 
> > 
> > Oh. Well- I'm hoping for compiler assist here. This is code that lives in
> > other than NetBSD. So- my question is still: will NetBSD sparc64's
> > compiler generate __sparc__ as well as __sparcv9__? Or is this just too
> > broken for NetBSD and I'll figure out a better way to do this? Perhaps I
> > should- based upon inclusion of some SBus header file that generate a
> > define- I mean, it's really an optimization to not have to do the swizzle
> > check for platforms/instances that can't possibly be SBus instances.
> 
> Things get a tad ugly.  SBus will use big-endian addressing and big-endian
> accesses.  PCI will use little endian addressing and little-endian
> accesses.  It is quite possible to have both SBus and PCI on the same
> machine.  PCI devices will either use a little-endian page mapping or a
> little-endian ASI in the bus_{read,write}_*() macros to access PCI
> register, control, and memory spaces.
> 
> What does this mean?  It's probably better to define all the registers as
> 16-bit entities so that endianness is handled automagically, and use
> macros to access the sub-fields. Otherwise things get ugly, requiring two
> different drivers for SBbus and PCI devices, based on some as yet
> non-existant SBUS/PCI define.
> 

It's not the registers here but the IOCBs. Without doing the complete
ddi_{put,get} foop that Solaris does (which might be nice to have but
isn't there now), the existing machines seem to boil down to only needing
to swizzle a couple of fields (target/lun and the IOCB header fields) for
initiator mode if the card in question is an SBus card (this is after
having run around with a variant solaris driver for Veritas that manages
SBus, PCI, Sparc, Intel, SCSI, FC, simultaneous target/initiator, all in
one package).

I've been wondering whether the E10K's could do pci && sbus at the same
time. You seem to indicate so. There's a runtime determinant in the
existing isp driver here that sez whether the card is SBus or PCI- the
only thing I was doing with the #ifdef was trying to not compile in that
test code for machines that can't possibly have an SBus (e.g., i386). I
was using __sparc__. Jason made reference to "sparc or sparc64" and I was
just trying to figure out from all of this whether __sparc__ would be
sufficient for all NetBSD sparc compilers so I wouldn't have to have sparc
or sparc64 as defines.

-matt