Cc: Mikael Pettersson <mikpe@...>, Richard Heck <rgheck@...>, Daniel Barkalow <barkalow@...>, Zan Lynx <zlynx@...>, Calvin Walton <calvin.walton@...>, Linux Kernel Mailing List <linux-kernel@...>, Linux ide Mailing list <linux-ide@...>
By the linux software definition maybe. But I've defined scsi as that which
uses a 50 wire cable using 50 contact centronics connectors since the
mid '70's, and which often needs a ready supply of nubile virgins to
sacrifice to make it work, particularly with the old resistor pack
terminations & psu's whose 5 volt line is only 4.85 volts due to old age.
That's what I call REAL scsi. Its also a REAL PITA if the terms aren't
active.
You can call what you are doing 'scsi' because you are using much the same
command structure, and that is good, but its not the real thing with all its
hardware warts and/or capabilities. For one thing, this version usually
works. :)
Furinstance, you can tell 2 scsi devices on the same controller to talk to
each other, moving files from one to the other, and the host controller can
then goto sleep & the cpu isn't involved until the devices send it a wakeup
to advise the controller that the transfer has been done, and the controller
may or may not then interrupt and advise the cpu. You can do that with
separate controllers too as long as they have a compatible DMA channel
available to both.
I doubt libata has that capability now, or ever will, cuz these ide/atapi
devices are generally dumber than rocks about that. But any device claiming
to be scsi-II is supposed to be able to do those sorts of things while the
cpu is off crunching numbers for BOINC or whatever.
But that puts my mild objections to classifying this as 'scsi' in a more
understandable context. :-)
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
When some people decide it's time for everyone to make big changes,
it means that they want you to change first.
--
