On Sat, 2008-03-15 at 19:26 +0100, Kay Sievers wrote: > On Sat, 2008-03-15 at 13:01 -0500, James Bottomley wrote: > > On Sat, 2008-03-15 at 11:16 -0500, James Bottomley wrote: > > > On Sat, 2008-03-15 at 16:17 +0100, Kay Sievers 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 > > > > > > with a back link in the component device pointing to the enclosure > > > component. > > > > > > The way components work, probably blowing away enclosure_component_class > > > makes the most sense anyway. > > > > OK, so this is the patch doing the above; is this what you had in mind? > > We're now managing all the links. > > Yeah, that looks fine. > > While I in general don't really like the <classname>:<devname> symlinks. > One needs to readdir() the whole device directory to find them, which is > not nice for a 1:1 relationship link between two devices. I would prefer > to be able to find an enclosure component for a LUN by simply looking > at: > /sys/bus/scsi/devices/0:0:0:0/enclosure/ > instead of searching for that composed link, because one can't predict > its name. Can there ever be more than one link from a device to an > enclosure? > > Also the "device" link, it will work to use that name, I guess, but it > has usually a different meaning, as all "device" links are just > meaninglessly pointing to the next parent device with !SYSFS_DEPRECATED. > With !SYSFS_DEPRECATED <classname>:<devname> links are no longer > created for any device, the class device directories just live in a > subdirectory with the class name. Right, but we can't do that with enclosure components, otherwise it really will be a multi rooted tree. > Do you prefer the <classname>:<devname>, "device" names? I'm not wedded to the name. I like the backlink because it tells me where a device is in the enclosure when I look at it, but it could be called anything. I chose those names to match what's in 2.6.24, but I suppose there aren't very many users yet, since it was new functionality in 2.6.24. If the backlink were called "enclosure_component", that would probably be fine. Not sure I have a better name than "device" for the actual device in the enclosure slot, though. 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