From: Luben Tuikov <luben_tuikov@adaptec.com>
To: dougg@torque.net
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
SCSI Mailing List <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH 2.6.13 2/14] sas-class: README
Date: Tue, 13 Sep 2005 09:30:54 -0400 [thread overview]
Message-ID: <4326D48E.1080305@adaptec.com> (raw)
In-Reply-To: <4326A635.3020400@torque.net>
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
next prev parent reply other threads:[~2005-09-13 13:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-09 19:39 [PATCH 2.6.13 2/14] sas-class: README Luben Tuikov
2005-09-11 1:44 ` Douglas Gilbert
2005-09-12 16:56 ` Luben Tuikov
2005-09-13 9:23 ` Douglas Gilbert
2005-09-13 13:20 ` Luben Tuikov
2005-09-12 9:00 ` Douglas Gilbert
2005-09-12 18:38 ` Luben Tuikov
2005-09-13 10:13 ` Douglas Gilbert
2005-09-13 13:30 ` Luben Tuikov [this message]
2005-09-13 14:29 ` Luben Tuikov
2005-09-13 10:17 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4326D48E.1080305@adaptec.com \
--to=luben_tuikov@adaptec.com \
--cc=dougg@torque.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox