From: Jeff Garzik <jgarzik@pobox.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org,
ltuikov@yahoo.com, Mike Anderson <andmike@us.ibm.com>,
Luben Tuikov <luben_tuikov@adaptec.com>,
James Bottomley <James.Bottomley@steeleye.com>,
Christoph Hellwig <hch@infradead.org>
Subject: Re: Adaptec SAS integration notes
Date: Tue, 18 Oct 2005 16:51:48 -0400 [thread overview]
Message-ID: <43556064.20104@pobox.com> (raw)
In-Reply-To: <43555CC1.8040200@s5r6.in-berlin.de>
Stefan Richter wrote:
> All transports implement HCIL mappings. (SPI drivers enjoy the easiest
> mapping, hcil<->HCIL.) They are all faced with the necessity of mapping
> and solve it in different ways, for different reasons. Why stop at FC +
> SAS and try to find a unified solution for just those two? Also, when
> you are working out how FC and SAS could interface to a common HCIL
> mapping library (or HCIL mapping layer?), you are effectively designing
> aspects of how an interface between FC|SAS and SCSI core should look
> like. Or, why not provide the HCIL mapping helpers in the core and
> subsequently make users of this new interface completely unaware of the
> existence of HCIL...?
Ignoring some legacy ioctls and bits of existing code... The only
mapping that's _really_ required is an internal C pointer, used by the
device class to send messages to the transport class.
Adaptec's code does a bit of that on the transport side, but we'd need
to update all the existing device classes (sd, sr, st, ...) before they
had been converted to a purely using pointers to connect the transport
to the device.
Getting to the point where device classes need only to do
transport_instance->send_message(scsi command | TMF)
and where the transport class replies with
device_instance->send_message(scsi response | TMF response)
may be a long term goal. Depends on where evolution takes us...
> Moreover, HCIL mapping is but one aspect of a common problem. As an
> example, I think yet another aspect of the same problem is that device
> properties like target names and LUNs get lost below the
> transport<->core interface. We want to present these device properties
> to userspace in a unified manner. Here it becomes even more clear:
> Neither is it a problem for FC and SAS alone, nor are transport-level
> helpers a good solution to the problem.
Target names are already in the generic device. Luben has a good point,
though, that there may be multiple "labels" for the same addressible object.
> I freely admit that I don't have a picture of where the real
> difficulties lie; I am far too unfamiliar with the innards of scsi core.
> But time spent on transport-level helpers which are meant to ease
> symptoms of the transport<->core difficulties seems to be spent rather
> ineffectively to me. More concrete, what is the ratio of benefit to cost
> of HCIL mapping code sharing between SAS and FC? Especially since that
> mapping is deemed obsolete already (in the long term or perhaps even mid
> term). And to completely go back to the subject: Will attempts on code
> sharing between FC layer and SAS layer bring things forward in the
> short-term goal of SAS integration?
HCIL mapping is a simple and very small part of this task :) There are
a bunch of line items to tackle, including SMP and SDI details, all
bundled up in this.
Jeff
next prev parent reply other threads:[~2005-10-18 20:51 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-12 18:40 Adaptec SAS integration notes Jeff Garzik
2005-10-12 18:55 ` Jeff Garzik
2005-10-14 18:06 ` Luben Tuikov
2005-10-15 14:19 ` Stefan Richter
2005-10-16 1:05 ` Douglas Gilbert
2005-10-17 6:35 ` Stefan Richter
2005-10-18 16:44 ` Jeff Garzik
2005-10-18 19:30 ` Luben Tuikov
2005-10-18 20:16 ` Jeff Garzik
2005-10-18 20:55 ` Luben Tuikov
2005-10-18 20:36 ` Stefan Richter
2005-10-18 20:51 ` Jeff Garzik [this message]
-- strict thread matches above, loose matches on Subject: below --
2005-10-15 14:21 James.Smart
2005-10-15 16:01 ` Stefan Richter
2005-10-18 15:06 ` Luben Tuikov
2005-10-18 16:12 ` Luben Tuikov
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=43556064.20104@pobox.com \
--to=jgarzik@pobox.com \
--cc=James.Bottomley@steeleye.com \
--cc=andmike@us.ibm.com \
--cc=hch@infradead.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=ltuikov@yahoo.com \
--cc=luben_tuikov@adaptec.com \
--cc=stefanr@s5r6.in-berlin.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.