Folks,
This discussion brings up some latent questions...
The transport can be a subsystem on it's own and is perhaps independent of SCSI altogether. In this case, SCSI just happens to be a personality of something on the transport. This is at odds with the current design in which the transport is something under SCSI and inherently bound to the SCSI "host".
Yes. This is something I really want to change, for libata.
I understand how we got to where we are, but shouldn't we consider making
some transports independent subsystems ? If the only protocol that
can be run on the transport is SCSI (ex: SPI), then the transport can be
under SCSI. However, if the transport can support multiple protocols (FC
can support SCSI, IP, (or ATA)), shouldn't it be structured more like an io
bus like pci ?
Unfortunately this is an open-ended question that Linux is rather poor at answering, since the answer could range from "no" to "show me the code" to "you're an absolute visionary!" :)
My own opinion:
I consciously avoid thinking too much in that direction. Linux development is a lot like a biological process. The evolution of the kernel code over time will give us the best answer.
Perhaps we will merge request_queue and network stack systems into a single "packet transport" system. Perhaps net stack and request_queue systems will stay separate, and request_queue will evolve into a generalized system for RPC message transport.
With the device model, both IDE [as of yesterday] and SCSI -already- export bus topology in a standardized manner, just like PCI.
Jeff
- : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
