All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Jeff Garzik <jeff@garzik.org>
Cc: brking@linux.vnet.ibm.com, linux-scsi@vger.kernel.org,
	thlin@linux.vnet.ibm.com, linux-ide@vger.kernel.org,
	miltonm@bga.com, Tejun Heo <htejun@gmail.com>
Subject: Re: [PATCH 1/1] ipr: Fix HDIO_GET_IDENTITY oops for SATA devices
Date: Mon, 02 Jun 2008 14:35:08 -0500	[thread overview]
Message-ID: <1212435308.3369.58.camel@localhost.localdomain> (raw)
In-Reply-To: <484437C3.8020306@garzik.org>

On Mon, 2008-06-02 at 14:11 -0400, Jeff Garzik wrote:
> James Bottomley wrote:
> > The quickest way seems to be to break the scsi_host <-> ata_port link by
> > mapping scsi_host <-> ata_host instead.
> 
> Correct for newer controllers... not desirable for older master/slave
> 
> 
> > Legacy controllers with only a
> > single port can keep the apparent 1:1 mapping (we can even keep the
> > hostdata stuff).
> 
> Not sure what you mean by this

I think it's possible to do the shift while still making it look to
single port hosts that nothing has changed

> > Unfortunately, the standard way of doing this is via
> > the transport classes, but as long as you have a pointer from the port
> > to the host and from the device to the port (which you do) it should be
> > possible.
> 
> I've always been open to an ATA transport class and thought that was the 
> best way to go long term.  But I confess to not knowing the best way to 
> implement that goal in concrete terms.

Perhaps it is best to approach it from what libsas needs, that way the
structures can be made to map to each other.

> > The downside I can see is that qc_defer handling changes non trivially
> > because of this, but there don't seem to be many other issues.
> 
> There are a lot of little details that are easily fixable.
> 
> The main detail is not breaking queueing for master/slave. 
> Master/slave, if you recall, _requires_ one-shost-per-port because it 
> relies on scsi queueing to handle the balancing between master/slave. 
> We set can_queue to 1, and for the 2-device case -- master and slave 
> present -- SCSI does the heavy lifting to ensure proper arbitration.

Well, we can be elastic on this.  The common case is a two port
master/slave, isn't it.  This particular one could just be treated as
two separate interfaces and hence two hosts (it's reasonably analagous
to the 53c896---which is a single chip that presents two SCSI channels
as two PCI functions).

> Adding support for NCQ and qc_defer made it a bit easier to change the 
> master/slave setup, though.
> 
> The other reason why we use one-short-per-port on master/slave is that, 
> in many respects, each legacy IDE port really can behave like a 
> completely separate controller, each port with its own interrupts and 
> independent reset logic.
> 
> Thus ATA really has two models:  1-port-1-host and N-ports-1-host.
> 
> [meta:  I'm not disagreeing with you here, just explaining how all this 
> came about...]

OK ... so how bad would it be to maintain two attachment models for the
two cases?  The architect in me says yuk because special casing like
this always leads to complexity, but I can't see a simpler way of doing
it.

James



  parent reply	other threads:[~2008-06-02 19:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <12124164141515-patch-mail.ibm.com>
2008-06-02 16:08 ` [PATCH 1/1] ipr: Fix HDIO_GET_IDENTITY oops for SATA devices Jeff Garzik
2008-06-02 16:27   ` Brian King
2008-06-02 16:45     ` James Bottomley
2008-06-02 17:43       ` Jeff Garzik
2008-06-02 17:57         ` James Bottomley
2008-06-02 18:11           ` Jeff Garzik
2008-06-02 18:51             ` Brian King
2008-06-02 18:54               ` Jeff Garzik
2008-06-02 19:39                 ` James Bottomley
2008-06-02 20:27                   ` Brian King
2008-06-02 19:35             ` James Bottomley [this message]
2008-06-02 19:53               ` Alan Cox
2008-07-11 18:37 Brian King
  -- strict thread matches above, loose matches on Subject: below --
2008-06-02 14:20 Brian King
2008-06-02 14:20 Brian King

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=1212435308.3369.58.camel@localhost.localdomain \
    --to=james.bottomley@hansenpartnership.com \
    --cc=brking@linux.vnet.ibm.com \
    --cc=htejun@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=miltonm@bga.com \
    --cc=thlin@linux.vnet.ibm.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.