On Sat, 2008-03-15 at 19:56 +0100, Kay Sievers wrote: > 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? Hmm, I suppose they might. Failure of an enclosure bay is most likely a failure of the device in that bay, but it could be for some other reason, I suppose. > 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? They can't be assigned to the enclosure class otherwise they'd get the enclosure class interface, which is wrong for components. > ... > > > | |-- 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? In this case, it is; but it's actually worse than that: the enclosure spec allows the enclosure device to be embedded in a LUN (i.e. a LUN responds as a SCSI disk but also responds to enclosure commands). That's why the ses driver has to bind like SG. > ... > > > 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. :) It would be nice, but then we run into the enumeration problem again. The names are taken from the actual enclosure information and are only guaranteed unique per enclosure. I could make up unique names, but then they wouldn't correspond with the actual names printed on the enclosure. > I still slightly prefer cross link-names between the component and the > LUN like "contains" -> and "enclosure" ->, but the current one should > work too. OK. James -- 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
