On Thu, Oct 4, 2012 at 9:56 AM, Gwendal Grignou [off-list ref] wrote:

quoted

What's the benefit of this?

+ To unify ata transport sysfs topology with other scsi transport.

My concern is the thrash and breakage to switch the ordering around
given the (minor) growing pains injecting an ata_port into the device
path caused.  Although, it seems like Aaron has caught where this
reversal broke things at the cost of some additional special-casing (4
files changed, 25 insertions(+), 13 deletions(-)).  Patch 1 also
creates a problem for bisections as the code that assumes
<dev>/port/host will break.

I don't know... I'm all for consistency, but if the only justification
is to make the transports look the "same" we'll still have a glaring
transport difference between ata and sas.  In the sas case one
hba/host spanning all possible sas domains vs the ata case of a
guaranteed ata_port per "ata domain" relationship with at least one
host per port.  The "port" does live higher in the topology in the ata
case.

+ To easily map a ata_port with its associated scsi_host structure.

Not sure this is getting any easier.  There would now be three options
based on kernel version: look for the ata_port as a host attribute,
look at the host's parent, or look for the host's child.

--
Dan