On Fri, 2008-03-14 at 16:20 -0500, James Bottomley wrote: > On Fri, 2008-03-14 at 12:15 -0500, James Bottomley wrote: > > On Thu, 2008-03-13 at 14:06 -0700, Greg KH wrote: > > > Here's a huge patch from Tony and Kay that converts the scsi layer to > > > use struct device instead of class_device. > > > > > > It doesn't seem like it could be split up any smaller due to the > > > interconectedness of the whole mess, if you have any suggestions > > > otherwise, it would be appreciated. > > > > > > If you want, I can take this through my tree as it does depend on a > > > previous IB patch to make that portion of the patch much smaller. > > > > > > After this, all of the class_device code is now finally gone from the > > > kernel! > > > > Actually, I have it built and running (actually 2.6.25-rc5-mc5 which > > includes all the changes in your tree). Amazingly it's pretty much > > fully functional, except ses which seems to have suffered a breakdown in > > the way its model works. I'll see if I can fix it up. > > OK, I looked at converting ses and enclosure, but it looks impossible > given the way you've set all of this up (and at the moment it's almost > non functional). > > What it wants is for the enclosure and component devices to be arranged > hierarchically under the enclosure class and then the device link of the > components to be populated if they're actually present (which they might > not be). > > Given the fact that you've chosen to have dev->parent point to the > device the original class_device->dev was pointing to, there's almost no > way left to express this relationship. We can do it by having > kobj->parent point to the enclosure and dev->parent point to the > enclosed device, but I can't encapsulate that information into a struct > device alone. > > >From an interface point of view, this dual use of the parent pointer > looks a bit nasty ... and you have some fun code to prove the point in > drivers/base/core.c:get_device_parent() > > How about just adding a struct device *peer; entry to struct device and > using it to express the former class relationship? That way we can do > all the parenting stuff correctly. > > Otherwise, I'm going to need something like a device_add_class_parent() > API that allows me to add these former class devices and set up the > kobject parent correctly. Unfortunately, the enclosure/enclusure-component/component-device relationship is not a tree. There is only a single "parent" for a device. The "device" link already expresses the parent device, and the class devices will show up as childs of the devices, where the "device" link pointed to. There can't be a second device which could be used as a parent. A sysfs class device hierarchy, and at the same let the "device" link point to a different device is not supported. Existing userspace tools do not support that. We have a similar problem for raid block devices, which can't be expressed in a single device tree. The "reverse tree" is constructed by custom holders/ slave/ directories at the devices. I suggest to express the relationship of the enclosure components to the enclosure device by custom symlinks, instead of expecting a "device" link maintained by the core to build a "reverse tree". Would that work? 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
