From: Mike Anderson <andmike@us.ibm.com>
To: Luben Tuikov <luben_tuikov@adaptec.com>
Cc: James Bottomley <James.Bottomley@SteelEye.com>,
ltuikov@yahoo.com, Jeff Garzik <jgarzik@pobox.com>,
Christoph Hellwig <hch@infradead.org>,
SCSI Mailing List <linux-scsi@vger.kernel.org>,
linuxraid@amcc.com
Subject: Re: [PATCH] 3ware: use scsi_scan_target()
Date: Sun, 9 Oct 2005 22:05:54 -0700 [thread overview]
Message-ID: <20051010050554.GA5822@us.ibm.com> (raw)
In-Reply-To: <4349448F.6040309@adaptec.com>
Luben Tuikov <luben_tuikov@adaptec.com> wrote:
> On 10/08/05 10:30, James Bottomley wrote:
> > But it doesn't represent a SCSI domain; it represents a particular type
> > of SCSI domain (as you say yourself, SAS or SATA). I'm trying to eject
>
> That's true.
>
> > transport specific knowledge from the mid-layer, so a domain device that
> > would be used in the mid-layer should be capable of representing any
> > SCSI domain (FC/SPI/SBP etc ..). I suppose in the worst case, anything
> > that comes back to the mid-layer from the transports should be relevant
> > to at least two separate transports.
>
> struct scsi_domain_device { ... }; (to be created) is your friend.
>
> The only way that that design
> "should be capable of representing any
> SCSI domain (FC/SPI/SBP etc ..)"
>
> Is if it _does not_ have any knowlege about the underlying
> physical domain -- just as it is shown in SAM (and that is the whole point).
> Else you get in this neverending cat-and-mouse game. If you have the
> abstraction right, then whatever new transport comes along, it would
> be properly represented.
>
> > Let Jeff come up with the incorporation scheme and see how it looks.
>
> Hmm, I haven't seen or heard anything from Jeff. Have you?
>
> I have no idea what his plans are. If the idea is to create
> struct scsi_domain_device { ... }; and start from there,
> then I'd like to be involved since this was what I'd wanted
> for SCSI since 2002.
>
I would also be interested in the incorporation work. I have been running
Luben's patches on a couple of x460s. I was also reading, hacking, and
experimenting on the two sas classes to understand them better and would
like to help if I can.
-andmike
--
Michael Anderson
andmike@us.ibm.com
next prev parent reply other threads:[~2005-10-10 5:05 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-04 0:57 [PATCH] 3ware: use scsi_scan_target() Jeff Garzik
2005-10-05 16:28 ` Christoph Hellwig
2005-10-05 19:01 ` Luben Tuikov
2005-10-05 19:20 ` adam radford
2005-10-05 19:24 ` Jeff Garzik
2005-10-05 19:34 ` Jeff Garzik
2005-10-05 23:19 ` Luben Tuikov
2005-10-07 1:07 ` James Bottomley
2005-10-07 21:36 ` Luben Tuikov
2005-10-08 14:30 ` James Bottomley
2005-10-09 16:25 ` Luben Tuikov
2005-10-10 5:05 ` Mike Anderson [this message]
2005-10-14 16:19 ` Luben Tuikov
-- strict thread matches above, loose matches on Subject: below --
2005-10-06 13:13 James.Smart
2005-10-06 18:09 ` 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=20051010050554.GA5822@us.ibm.com \
--to=andmike@us.ibm.com \
--cc=James.Bottomley@SteelEye.com \
--cc=hch@infradead.org \
--cc=jgarzik@pobox.com \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxraid@amcc.com \
--cc=ltuikov@yahoo.com \
--cc=luben_tuikov@adaptec.com \
/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.