On 09/13/05 06:13, Douglas Gilbert wrote: > > That is a relief, retired at last. C'mon, you and I both know that sg has its place, and is perfect doing what it is doing now. But for protocol _interjection_, the mecanism posted is easiest and sanest. > It is impressive how elegant a passthrough can be when I cannot call it a "passthrough" since the SMP frame isn't "passing though" (by passing) anything. When userspace does a read(2) to get the data they expect, the SMP frame they wrote(2) is sent to the SDS immediately. In effect there is no "passing through". It is a _protocol_ interjection. That is an SMP frame (submission) _instantiates_ at that layer/level, not lower, not higher. > one dispenses with a bit of metadata such as per command > timeouts and 3 levels of error messages (i.e. from the > driver, from the link layer and from the SMP target). > I always enjoy getting EIO in errno. > > This all seems so frustrating; a LLD injects a > command/frame/whatever into an initiator and waits for > a response or something to happen. Networking code faces > the same scenario and presents it "as is" to the user > space (for any application that cares). Yes, there are > messy details. However in the SCSI subsystem we want to > hide this simple reality with all these wierd and > wonderful abstractions. Doug, SMP is what it is, and this is where it _instantiates_. You have to agree that interjecting an SMP frame at any other level would be _more_ messy. Plus, I always like presenting things "as is" to userspace or higher layer, to keep the current layer cleaner and concerned only with things belonging to it. Luben - : 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