On Sat, 2008-03-15 at 13:31 -0500, James Bottomley wrote: > On Sat, 2008-03-15 at 19:04 +0100, Kay Sievers wrote: > > On Sat, 2008-03-15 at 11:16 -0500, James Bottomley wrote: > > > > We just need to create something like a "contains" link from the > > > > component to the scsi device, and a "enclosure" link at the scsi device > > > > back to the component, right? > > > > > > Assuming you're moving to the single tree model, then I can easily do > > > this: > > > > > > <real enclosure device>/<enclosure>/<enclosure component>/device -> link > > > to component device > > > > Yes, sounds good. Only that there will be no meaningful "device" link > > with !SYSFS_DEPRECATED, we need a custom link, maintained by the > > enclosure itself, to do that. > > > > > with a back link in the component device pointing to the enclosure > > > component. > > > > That sounds fine. > > > > > The way components work, probably blowing away enclosure_component_class > > > makes the most sense anyway. > > > > If we go for a single class, can't we express enclosures and components > > in the device name and put them in the same class like: > > /sys/class/enclosure/ > > |- enclosure1 -> ../../../devices/<...>/enclosure1 > > |- enclosure1.slot1 -> ../../../../devices/<...>/enclosure1/enclosure1.slot1 > > |- enclosure1.slot2 -> ../../../../devices/<...>/enclosure1/enclosure1.slot2 > > |- enclosure2 -> ../../../devices/<...>/enclosure2 > > |- enclosure2.slot1 -> -> ../../../../devices/<...>/enclosure1/enclosure2.slot1 > > ... > > > > while /sys/devices/<...>/enclosure1/enclosure1.slot1/ has a something > > like a "contains" link pointing to the SCSI device, and the SCSI device > > an "enclosure" link back? > > OK, I've got a two expander system with six slots each pretending to be > a twelve slot installation. I've also got two slots populated (slot 1 > and 6). This is what it looks like with the deprecated setting: > > sparkweed:/sys/class/enclosure# tree > . > |-- 0:0:1:0 > | |-- SLOT 006 > | | |-- active > | | |-- device -> ../../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0/expander-0:0/port-0:0:0/end_device-0:0:0/target0:0:0/0:0:0:0 > | | |-- fault > | | |-- locate > | | |-- power > | | | `-- wakeup > | | |-- status > | | |-- type > | | `-- uevent The components are not assigned to any subsystem. Userspace will not see any event for these devices, which might not be nice. Is that expected behavior? If you assign them to the enclosure class, the device name would need the enclosure name prefixed, because they are not unique across different enclosures, right? ... > | |-- SLOT 011 > | | |-- active > | | |-- fault > | | |-- locate > | | |-- power > | | | `-- wakeup > | | |-- status > | | |-- type > | | `-- uevent > | |-- components > | |-- device -> ../../../devices/pci0000:01/0000:01:02.0/host0/port-0:0/expander-0:0/port-0:0:12/end_device-0:0:12/target0:0:1/0:0:1:0 Oh, interesting, can the parent for a whole enclosure be a SCSI LUN? Is that because the expander _is_ a LUN itself? ... > So are we now all happy? If we don't need uevents for components, and no directory in /sys/class/ which lists all enclosure components for easy finding them. And if we never want to send things link "change" events to userspace from an enclosure component, that should be ok. And we can be happy, yes. :) I still slightly prefer cross link-names between the component and the LUN like "contains" -> and "enclosure" ->, but the current one should work too. Thanks, Kay -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
