On Fri, 16 Jul 1999, Grant Stockly wrote:

> I thought BSD used the toolbox to do things like video, so I thought it
> might be able to find the scsi controller.

We already have a driver for the scsi chip. The whole point of the
impending complaints about what you're doing is that you're wanting to
side-step this controller. Don't! :-)

> >If it follows the standard, forget about talking to the hardware directly.
> >You don't need to. Just make your driver a scsi device driver, and it'll
> >be able to feed SCSI commands to the SCSI bus. Then you won't have to
> >worry about where this chip is or what kind of chip that machine has -
> >it'll just work.
> 
> Do you know where I can find information about writing and reading SCSI
> commands (specifically Target?)?

SCSI speaks of Initiator & Target. It's the thing being spoken to, not a
type of command.

> >I'd suggest you look at both the se and uk drivers. The se is SCSI
> >Ethernet - a prime example of a driver making a scsi device look like
> >something other than mass storage (i.e. an ethernet driver).
> 
> Ok.  Would the se driver drive the SCSI Ethernet device on any NetBSD
> computer capable of doing SCSI?

Yes. :-) As long as it's one of the SCSI Ethernet devices we support, it
works. If you design your driver(s) to work on the same level (they attach
to a scsibus), it'll be transportable.

> >Also look at the uk driver. It's the "unknown" driver, for unknown SCSI
> >devices. It will let you generate scsi commands from userspace, and it
> >should be matching your device now (if it's config'd in your kernel). It
> >will let you focus on figuring out how to talk to your device from
> >userland. Then once you have things figured out, you can work on making a
> >kernel driver. It should save you a lot of time & effort.
> 
> Thanks!  I didn't know that!

Enjoy. ;-)

Take care,

Bill