Subject: Re: reconfirm- Re: CVS commit: src
To: None <eeh@netbsd.org>
From: Matthew Jacob <mjacob@feral.com>
List: port-sparc
Date: 04/07/1999 11:11:56
> > 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'll need to think a bit about this one.  In theory DVMA mapped pages
> could also be mapped little-endian for PCI devices, at least in the case
> of the IOCBs, so once again this could be made transparent as long as
> these fields are only accessed 16-bits at a time.  Endianness gets really
> complicated when put into practice 8^).

*That* certainly is true!


> 
> > 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
> 
> Actually E3K, E4K, E5K, and E6Ks can have both SBus and PCI ISP
> controllers on them at the same time.  The PCI I/O boards come with a
> built-in ISP1040, but the only `supported' way to connect an A3000 to an
> E4000 is with an ISP1000.

Ah- I have limited h/w to play with sometimes, so I really had
better plan for simultaneous...

> 
> > 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.
> 
> Probably want to use MACHINE == sparc or MACHINE == sparc64 since that's
> what you get in the kernel.  I wouldn't count on anything that isn't
> explicitly defined by the makefile or some header file since that can
> change if a different compiler is used.


Okay. I'll punt it to the isp_{OS}.h files and NetBSD can do the
sparc/sparc64 dance. Thanks.


-matt