Hi Tejun, 1- the hierarchy In the case CONFIG_SYSFS_DEPRECATED is not set, here is the view of ATA topology in sysfs: [I can describe when CONFIG_SYSFS_DEPRECATED is set upon request] The parent of the hierarchy is the device object given when the ata host object is created. In the following example of a ATA controller on a PCI bus, the current directory is the pci directory of the controller - "/sys/devices/pci0000:00/0000:00:1f.2". If there is no port multiplier are connected connected to a port, we would find: ata1 <== 1 is the port_id of the port ata1/ata_port ata1/ata_port/ata1 <== directory where sysfs attributes are ata1/link1 ata1/link1/ata_link ata1/link1/ata_link/link1 <== directory where sysfs attributes are ata1/link1/dev1.0 ata1/link1/dev1.0/ata_device ata1/link1/dev1.0/ata_device/dev1.0 <== directory where sysfs attributes are ata1/link1/dev1.1 <== If controller can support 2 devices per link, a second device created even if there is not slave disk attached ata1/link1/dev1.1/ata_device ata1/link1/dev1.1/ata_device/dev1.1 If there is a port multiplier, 15 links are created in addition: ata5 ata5/ata_port ata5/ata_port/ata5 ata5/link5 <====== host link ata5/link5/ata_link ata5/link5/ata_link/link5 ata5/link5/dev5.0 <==== device behind the host link [port multiplier] ata5/link5/dev5.0/ata_device ata5/link5/dev5.0/ata_device/dev5.0 ata5/link5.0 <=== first link behind the PM, port 0 ata5/link5.0/ata_link ata5/link5.0/ata_link/link5.0 ata5/link5.0/dev5.0.0 <=== device object for sata device connected in port 0 of the PM [if any] ata5/link5.0/dev5.0.0/ata_device ata5/link5.0/dev5.0.0/ata_device/dev5.0.0 ata5/link5.1 ata5/link5.1/ata_link ata5/link5.1/ata_link/link5.1 ata5/link5.1/dev5.1.0 ata5/link5.1/dev5.1.0/ata_device ata5/link5.1/dev5.1.0/ata_device/dev5.1.0 ata5/link5.2 ata5/link5.2/ata_link ata5/link5.2/ata_link/link5.2 ata5/link5.2/dev5.2.0 ata5/link5.2/dev5.2.0/ata_device ata5/link5.2/dev5.2.0/ata_device/dev5.2.0 ... ata5/link5.14 ata5/link5.14/ata_link ata5/link5.14/ata_link/link5.14 ata5/link5.14/dev5.14.0 <=== device object for sata device connected in port 14 of the PM [if any] ata5/link5.14/dev5.14.0/ata_device ata5/link5.14/dev5.14.0/ata_device/dev5.14.0 I describe the current information you can find in these object in Documentation/ABI/testing/sysfs-ata in the latest version of the patch. 2- sysfs object lifecycle I try to sync sysfs object lifetime with libata object lifetime rules. Given libata creates objects statically, I decided to create related sysfs objects at almost the same time, even if they are not populated: For port object, I have to wait for for print_id to be set. In the latest version of the patch [v4], I create the sysfs port object before calling ata_scsi_add_host(). The sysfs link object for the host link is created when the port object is created. Related ata_link has been initialized before. When a SATA PMP is found, all sysfs link objects are created in sata_pmp_init_links(), if the data structure to hold the links behind the PMP did not exist already. Given sysfs link objects are always created after ata_link_init() and ata_dev_init() are called, sysfs ata_device object are implicitly created when the links are created. Given during error handling link and device ata objects are wiped out instead of being freed, I alter memset() for link and devices to not include fields holding sysfs information. For cleanup: All sysfs related objects are deleted in ata_port_detach, called when .remove entry point of a ATA driver is called. I was tempted to add objects only when they are useful [for instance, creating only the required number of links object behind the PMP], but I balked away; as you point out, the lifecycle is quite different from scsi_device for instance, and I did not want to change the logic of libata. Also, I tried to create a link between scsi_device and ata_device object when appropriate, but I was not successful: scsi_device sysfs objects are created after slave_configure is called, so I did not find an easy hook in libata to create the link. Thanks, Gwendal. On Wed, Aug 20, 2008 at 1:17 AM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Gwendal Grignou wrote: >>>From df84b33306569f8247f331fd67b0a7e7dfb47936 Mon Sep 17 00:00:00 2001 >> From: Gwendal Grignou <gwendal@xxxxxxxxxx> >> Date: Mon, 18 Aug 2008 14:02:09 -0700 >> Subject: Add transport class for libata. >> >> This patch adds objects for accessing libata objects from user space: >> - ata_port class: one per ATA port >> - ata_link class: one per ATA port or 15 for SATA Port Multiplier >> - ata_device class: up to 2 for PATA link, usually one for SATA. >> >> Each object exports information from the corresponding data strucure. >> For instance, ata_device exports id, the cached identify output if >> the device is a disk, gscr register output if it is a PM. >> >> More fields can be added later, like error counters and ATA specific >> statistics. > > Ah... I'm not so sure about the class transport approach although I do > agree that sysfs hierarchy for libata is way overdue. Hmmm... Can you > please explain the planned hierarchy and how you're gonna match lifetime > rules? Because libata uses very different object lifetime rules from > the generic driver layer, it can get ugly at times and from a quick > glance I don't really think the problem has been addressed but I could > have just missed it. > > Thanks. > > -- > tejun > -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
