On Sat, 2008-03-15 at 14:33 -0500, James Bottomley wrote: > 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. If we can distinguish the both device types by the device name, that would still be fine. Like we have disks and partitions in "block, or mouseX and inputX in "input" at the same time. Or we can have a separate classes, like it was in the original version, if that fits better. > > ... > > > > > | |-- 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. Ouch! People have crazy ideas. :) > > ... > > > > > 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. If we prefix the component device name with the enclosure device name, like: "<encl-name>.<comp-name>", it would be unique, right? And still match the labels, and also identify 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. 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
