5 Nov
2010
5 Nov
'10
1:43 p.m.
Dave McGuire wrote:
Maybe - but I've found an awful lot of old systems and devices that are a bit
flakey when it comes to their SCSI implementations (not to mention things
which send vendor-specific commands for control and setup); personally I think
I'd rather have the transfer in "user-land" than try to seamlessly integrate
it with a modern protocol.
I get the impression (possibly wrong!) that something like iSCSI (and a
back-end PC making use of it) might get tripped up by some vintage systems,
but something doing the interpretation in user-space could easily be coded to
cope.
cheers
Jules
On 11/5/10 12:34 PM, Jules Richardson wrote:
If you say so :-)
I do. :) I don't much relish the idea of connecting a big thick SCSI
cable between two computers when the connection is going to end up being
temporary. It just sounds like a pain.
Yeah, I saw it as the board being local to the vintage system, rather than
local to the modern storage system - so the only cabling between systems would
be a cat5 cable (or some sort of wireless widget I suppose, but urgh :-)
> It should be fairly simple to modify the SCSI
target disk mode code
> to pretend it's a SCSI tape.
Did I heard on the back "SCSI-to-SD-card-Adapter-open-source"????? :oD
That's what I was just thinking about. That's a MUCH nicer solution
than connecting it to a computer somewhere. I'd quite
like a SCSI<->Ethernet bridge, I think.
Something that can spit SCSI commands over the network to a remote
machine. I could quite easily write some code to listen on a socket and
interpret those commands in whatever way was useful (which would include
pulling data from a file and just looking like a big ol' disk).
That'd be pretty easy; it could basically be a transport layer
translator to bridge parallel SCSI with iSCSI.