Re: [patch] convert the scsi layer to use struct device

[Kay Sievers <kay.sievers@vrfy.org>]

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html