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. 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
