Thread (20 messages) 20 messages, 5 authors, 2012-10-07

Re: Change in sysfs topology for libata

From: Lin Ming <hidden>
Date: 2012-09-13 15:38:53

On Thu, Sep 13, 2012 at 4:07 AM, Gwendal Grignou [off-list ref] wrote:
[-Lin, +Lin]
CC Aaron@Intel
On Wed, Sep 12, 2012 at 1:02 PM, Gwendal Grignou [off-list ref] wrote:
quoted
Lin,

 Commit 9a6d6a2ddabbd32c07f6a38b659e5f3db319fa5a introduces a change
in sysfs directory for ata controller:

Before:
           /sys/devices/pci0000:00/0000:00:1f.2    (ahci controller)
           |-- ata1                                (ata port)
           |-- host0                               (scsi host)
              |-- target0:0:0                      (scsi target)
                  |-- 0:0:0:0                      (disk)

After:
           /sys/devices/pci0000:00/0000:00:1f.2    (ahci controller)
           |-- ata1                                (ata port)
               |-- host0                           (scsi host)
                   |-- target0:0:0                 (scsi target)
                       |-- 0:0:0:0                 (disk)

The problem is an ata controller, managed by libata, is still
considered by the kernel as a SCSI controller: diverging even more
from other SCSI controller sysfs layout is not a good idea.
When I wrote libata-transport.c, my plan was to be consistent with SAS
objects: for instance, for a SAS controller with a simple SAS topology
we have:


/sys/bus/pci/devices/0000\:0c\:00.0/
|-- host7/
    |-- phy-7:0
    |-- phy-7:1
..
    |-- phy-7:7
    |-- port-7:0
        |-- end_device-7\:0
            |-- target7:0:0/
                |-- 7:0:0:0
    |-- port-7:1
..

Similarly, I wanted to represent an ata_port [equivalent to SAS phy]
and ata_link [equivalent to SAS port] under scsi_host hostX object,
but as far as i remember, when I wrote the code that was not possible,
I could not find a clean way to share object references between libata
and scsi layer. That's why ata_port object was sitting alongside to
the scsi_host object. I have to see if it is possible now.

In the meantime, what would be the impact to revert that commit?
Do you think melting libata sysfs object into scsi sysfs objects would
work with your changes related to pm?
The SATA disk runtime pm and ZPODD(Zero Power ODD) relies on the new
sysfs directory I introduced in commit 9a6d6a2.

Could you show me what's the sysfs directory structure after libata
sysfs object melted into scsi sysfs objects?

Thanks,
Lin Ming
quoted
Thanks,

Gwendal.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help