> > The real problem with SCSI is that it is not really designed for
> > networking.  The address space is limited to 8 devices in SCSI, 16 in
> > SCSI-2.  It won't be a big network :-)
> 
> I'll be quite satisfied to put two hosts on it. :)  (Two hosts, plus
> one disk drive for one, two drives and a tape for the other, that's six
> devices right there.  It's going to be a bit crowded. :)

I don't see any reason why you can't have multiple nodes, but it would
probably be easier to configure it logically as multiple point to point
links.

I have given this considerable thought for the pc532, but never quite
got to implementation. SCSI ID can be got from hardware (dip switches,
nvram or whatever), set at kernel config time or using sysctl.
All the old chip level devices I know of can set the scsi ID.

We need a generic target mode scsi layer as well as hardware adaptor
driver support and finally logical scsinet device support. The top
layer is pretty much like the ea41x driver we have. There is
no shortcut for the bottom level chip or adaptor support but I don't
expect it is that hard if the middle layer has reasonable support.

The middle layer is missing. The ea41x has to be polled to receive
packets and that is to be avoided if possible. Without polling, I
can see two ways of doing this:

a) Symmetrically. This is easiest. Both ends act as initiators and targets.
   Data is always sent with a "write" command. The hard bit comes when
   you want to handle a target which is not ready. You could just drop
   the packet and expect tcp to fix it up, or you could
   disconnect. Supporting disconnect would be quite a lot of extra
   work but is undoubtedly the best.

b) Asymmetrically. I think an asymmetric configuration could be done by
   the host issuing a read command, the target disconnects until it
   has something.  If the host wants to send something before the read
   is complete, it either aborts the read command (using an abort
   message) or you implement support for multiple outstanding commands
   (tagged queueing) at both ends. You would only do this if one end
   had hardware it was particularly difficult to do target mode for.

I think the hard part to doing this well is designing the middle layer
well. Obviously it would be desirable to have as little adaptor/chip
dependent code as possible.

Ian