convert the scsi layer to use struct device

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!

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!

Quoted 10 lines · Greg KH

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.

Quoted 2 lines

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.

From an interface point of view, this dual use of the parent pointer

Quoted 11 lines · James Bottomley

Quoted 10 lines · Greg KH

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 1 line

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.

Quoted 40 lines · James Bottomley

Quoted 11 lines · James Bottomley

Quoted 10 lines · Greg KH

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 1 line

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()

Quoted 7 lines

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?

Quoted 49 lines · Kay Sievers

Quoted 40 lines · James Bottomley

Quoted 11 lines · James Bottomley

Quoted 10 lines · Greg KH

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.

Quoted 7 lines

Quoted 2 lines

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.

Quoted 1 line

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()

Quoted 7 lines

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.

Quoted 6 lines

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.

But that's precisely my point: it is a tree; it's not a multi rooted tree either.

Each enclosure has a fixed number of components (the bays
in the enclosure) that's a simple two level tree.

However, both the
enclosure and the components may point to devices in the regular tree (bays only if the bay is actually populated).

This was formerly representable in the class_device infrastructure, because class devices were allowed to have parents.

Class devices are
supposed to represent interfaces to devices

and not all interfaces are
fully flat.

Quoted 8 lines

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.

Quoted 5 lines

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?

There are still several problems with the symlink approach; not least of which is that the component namespace isn't globally unique, it's only unique to the enclosure: If you have two separate enclosures connected, they're likely each going to have a component called slot1 (the name is actually take from the enclosure). I also think we're going to have difficulty going back from a component to an enclosure, which was pretty much the whole point of the exercise but I need to get ses/enclosure actually working to look at that.

Quoted 9 lines · James Bottomley

Quoted 7 lines · Kay Sievers

On Fri, 2008-03-14 at 16:20 -0500, James Bottomley wrote:
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.

Quoted 2 lines

But that's precisely my point: it is a tree; it's not a multi rooted tree either.

Hmm, the enclosure components have two parents in this model, the enclosure itself _and_ the scsi device, so it's not a flat tree anymore.

Quoted 2 lines

Each enclosure has a fixed number of components (the bays
in the enclosure) that's a simple two level tree.

I think it's not a second level, it's a second tree if you have two parents for one single node. The driver core only supports one flat device tree, and one parent relationship per device.

Quoted 3 lines

However, both the
enclosure and the components may point to devices in the regular tree (bays only if the bay is actually populated).

Sure, that's fine, but still, the component can have only one parent managed by the core, we have only one single device tree
at /sys/devices/ and other relations should be expressed by the driver itself.

Quoted 2 lines

This was formerly representable in the class_device infrastructure, because class devices were allowed to have parents.

The "parent" field was something Greg added for trying to represent "input", and it failed, existing userspace logic could not handle it, and we immediately deprecated hierarchies in /sys/class. It was never supposed to be used with the "dev" field pointing to a different device at the same time.
As documented in Documentation/, all this "device" link magic we are talking about, will only work in SYSFS_DEPRECATED=y mode anyway, which no recent distro uses anymore, and the enclosure stuff was added long after that.

Quoted 2 lines

Class devices are
supposed to represent interfaces to devices

That's not true. Class devices are just devices, as documented in the Documentation/ directory.

Class devices are _not_ supposed to be
anything special, they just don't have drivers/binding in the kernel internals - no other difference. There is no such thing as an "interface" in the driver core or sysfs. Every device _is_ the interface itself, otherwise devices would have no functional sysfs attributes.

It was one of the biggest mistakes to expose such a kernel implementation details as different entities to userspace, and one reason sysfs is that hard to understand. The guy who did all that just ran away leaving all this mess behind him. :) And yes, we are too slow cleaning all that up, but we will get there over time.


Quoted 2 lines

and not all interfaces are
fully flat.

True, but the core is only one flat tree, the drivers need to express "reverse trees" themselves, just like the raid block devices do.

Quoted 14 lines

Quoted 8 lines

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.

Quoted 5 lines

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?

Quoted 8 lines

There are still several problems with the symlink approach; not least of which is that the component namespace isn't globally unique, it's only unique to the enclosure: If you have two separate enclosures connected, they're likely each going to have a component called slot1 (the name is actually take from the enclosure). I also think we're going to have difficulty going back from a component to an enclosure, which was pretty much the whole point of the exercise but I need to get ses/enclosure actually working to look at that.

Hmm, I don't understand. The only thing that changed is that you don't have a core-managed "device" link at the enclosure component anymore, nothing else should be different. The namespace issue should be the same as it was before, right?

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?

Quoted 3 lines · Kay Sievers

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.

Quoted 11 lines · James Bottomley

Quoted 3 lines · Kay Sievers

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

Quoted 5 lines

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.

drivers/misc/enclosure.c +71 -26

index fafb57f..0736cff 100644
@@ -31,7 +31,6 @@
 static LIST_HEAD(container_list);
 static DEFINE_MUTEX(container_list_lock);
 static struct class enclosure_class;
-static struct class enclosure_component_class;
 
 /**
  * enclosure_find - find an enclosure given a device

@@ -166,6 +165,40 @@ void enclosure_unregister(struct enclosure_device *edev)
 }
 EXPORT_SYMBOL_GPL(enclosure_unregister);
 
+#define ENCLOSURE_NAME_SIZE	64
+
+static void enclosure_link_name(struct enclosure_component *cdev, char *name)
+{
+	strcpy(name, "enclosure_device:");
+	strcat(name, cdev->cdev.bus_id);
+}
+
+static void enclosure_remove_links(struct enclosure_component *cdev)
+{
+	char name[ENCLOSURE_NAME_SIZE];
+
+	enclosure_link_name(cdev, name);
+	sysfs_remove_link(&cdev->dev->kobj, name);
+	sysfs_remove_link(&cdev->cdev.kobj, "device");
+}
+
+static int enclosure_add_links(struct enclosure_component *cdev)
+{
+	int error;
+	char name[ENCLOSURE_NAME_SIZE];
+
+	error = sysfs_create_link(&cdev->cdev.kobj, &cdev->dev->kobj, "device");
+	if (error)
+		return error;
+
+	enclosure_link_name(cdev, name);
+	error = sysfs_create_link(&cdev->dev->kobj, &cdev->cdev.kobj, name);
+	if (error)
+		sysfs_remove_link(&cdev->cdev.kobj, "device");
+
+	return error;
+}
+
 static void enclosure_release(struct device *cdev)
 {
 	struct enclosure_device *edev = to_enclosure_device(cdev);

@@ -178,10 +211,15 @@ static void enclosure_component_release(struct device *dev)
 {
 	struct enclosure_component *cdev = to_enclosure_component(dev);
 
-	put_device(cdev->dev);
+	if (cdev->dev) {
+		enclosure_remove_links(cdev);
+		put_device(cdev->dev);
+	}
 	put_device(dev->parent);
 }
 
+static struct attribute_group *enclosure_groups[];
+
 /**
  * enclosure_component_register - add a particular component to an enclosure
  * @edev:	the enclosure to add the component

@@ -217,12 +255,14 @@ enclosure_component_register(struct enclosure_device *edev,
 	ecomp->number = number;
 	cdev = &ecomp->cdev;
 	cdev->parent = get_device(&edev->edev);
-	cdev->class = &enclosure_component_class;
 	if (name)
 		snprintf(cdev->bus_id, BUS_ID_SIZE, "%s", name);
 	else
 		snprintf(cdev->bus_id, BUS_ID_SIZE, "%u", number);
 
+	cdev->release = enclosure_component_release;
+	cdev->groups = enclosure_groups;
+
 	err = device_register(cdev);
 	if (err)
 		ERR_PTR(err);

@@ -255,10 +295,12 @@ int enclosure_add_device(struct enclosure_device *edev, int component,
 
 	cdev = &edev->component[component];
 
-	device_del(&cdev->cdev);
+	if (cdev->dev)
+		enclosure_remove_links(cdev);
+
 	put_device(cdev->dev);
 	cdev->dev = get_device(dev);
-	return device_add(&cdev->cdev);
+	return enclosure_add_links(cdev);
 }
 EXPORT_SYMBOL_GPL(enclosure_add_device);
 

@@ -442,24 +484,32 @@ static ssize_t get_component_type(struct device *cdev,
 }
 
 
-static struct device_attribute enclosure_component_attrs[] = {
-	__ATTR(fault, S_IRUGO | S_IWUSR, get_component_fault,
-	       set_component_fault),
-	__ATTR(status, S_IRUGO | S_IWUSR, get_component_status,
-	       set_component_status),
-	__ATTR(active, S_IRUGO | S_IWUSR, get_component_active,
-	       set_component_active),
-	__ATTR(locate, S_IRUGO | S_IWUSR, get_component_locate,
-	       set_component_locate),
-	__ATTR(type, S_IRUGO, get_component_type, NULL),
-	__ATTR_NULL
+static DEVICE_ATTR(fault, S_IRUGO | S_IWUSR, get_component_fault,
+		    set_component_fault);
+static DEVICE_ATTR(status, S_IRUGO | S_IWUSR, get_component_status,
+		   set_component_status);
+static DEVICE_ATTR(active, S_IRUGO | S_IWUSR, get_component_active,
+		   set_component_active);
+static DEVICE_ATTR(locate, S_IRUGO | S_IWUSR, get_component_locate,
+		   set_component_locate);
+static DEVICE_ATTR(type, S_IRUGO, get_component_type, NULL);
+
+static struct attribute *enclosure_component_attrs[] = {
+	&dev_attr_fault.attr,
+	&dev_attr_status.attr,
+	&dev_attr_active.attr,
+	&dev_attr_locate.attr,
+	&dev_attr_type.attr,
+	NULL
 };
 
-static struct class enclosure_component_class =  {
-	.name			= "enclosure_component",
-	.owner			= THIS_MODULE,
-	.dev_attrs	= enclosure_component_attrs,
-	.dev_release		= enclosure_component_release,
+static struct attribute_group enclosure_group = {
+	.attrs = enclosure_component_attrs,
+};
+
+static struct attribute_group *enclosure_groups[] = {
+	&enclosure_group,
+	NULL
 };
 
 static int __init enclosure_init(void)

@@ -469,20 +519,12 @@ static int __init enclosure_init(void)
 	err = class_register(&enclosure_class);
 	if (err)
 		return err;
-	err = class_register(&enclosure_component_class);
-	if (err)
-		goto err_out;
 
 	return 0;
- err_out:
-	class_unregister(&enclosure_class);

Quoted 12 lines · James Bottomley

Quoted 11 lines · James Bottomley

Quoted 3 lines · Kay Sievers

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

Quoted 8 lines

Quoted 5 lines

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.

Do you prefer the <classname>:<devname>, "device" names?

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.

Quoted 10 lines · Kay Sievers

Quoted 9 lines · James Bottomley

Quoted 7 lines · Kay Sievers

On Fri, 2008-03-14 at 16:20 -0500, James Bottomley wrote:
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.

Quoted 5 lines

Quoted 2 lines

But that's precisely my point: it is a tree; it's not a multi rooted tree either.

Hmm, the enclosure components have two parents in this model, the enclosure itself _and_ the scsi device, so it's not a flat tree anymore.

Only because you're expressing the class relationship as a parent.

It wasn't designed like this; an interface sits off to the side.

Quoted 19 lines

Quoted 2 lines

Each enclosure has a fixed number of components (the bays
in the enclosure) that's a simple two level tree.

I think it's not a second level, it's a second tree if you have two parents for one single node. The driver core only supports one flat device tree, and one parent relationship per device.

Quoted 3 lines

However, both the
enclosure and the components may point to devices in the regular tree (bays only if the bay is actually populated).

Sure, that's fine, but still, the component can have only one parent managed by the core, we have only one single device tree
at /sys/devices/ and other relations should be expressed by the driver itself.

Quoted 2 lines

This was formerly representable in the class_device infrastructure, because class devices were allowed to have parents.

Quoted 9 lines

The "parent" field was something Greg added for trying to represent "input", and it failed, existing userspace logic could not handle it, and we immediately deprecated hierarchies in /sys/class. It was never supposed to be used with the "dev" field pointing to a different device at the same time.
As documented in Documentation/, all this "device" link magic we are talking about, will only work in SYSFS_DEPRECATED=y mode anyway, which no recent distro uses anymore, and the enclosure stuff was added long after that.

OK, where is this? There's no mention of any deprecation in Documentation/driver-model; grep -i deprec returns an empty list.

Quoted 5 lines

Quoted 2 lines

Class devices are
supposed to represent interfaces to devices

That's not true. Class devices are just devices, as documented in the Documentation/ directory.

OK, which kernel is this? The latest greatest upstream merge kernel I know is 2.6.25-rc5-mc6 and that says

Documentation/driver-model/class.txt:
[...]
Each device class defines a set of semantics and a programming interface that devices of that class adhere to. Device drivers are the implementation of that programming interface for a particular device on a particular bus.

The "programming interface" bit seems pretty clear to me.

The whole of SCSI use of the driver model is designed around the interface concept. Essentially, SCSI device represents the generic object that sits on the end of the bus. We export one set of interfaces from the upper layer driver that binds (st, sd, sr etc.) we express another through the SCSI generic, and we express a third (or more) through the transport class interfaces.

In theory, we could express all this as simply additional attribute groups on the generic SCSI device or use a parent/child device relationship for them, or something else ... This is the piece I still don't get from you and Greg. Just saying it isn't an interface any more doesn't help me in this regard.

Quoted 5 lines

Class devices are _not_ supposed to be
anything special, they just don't have drivers/binding in the kernel internals - no other difference. There is no such thing as an "interface" in the driver core or sysfs. Every device _is_ the interface itself, otherwise devices would have no functional sysfs attributes.

But if the actual class documentation doesn't say this, how am I supposed to know it? I keep asking what you're planning but I don't get a complete response.

If I had to guess, I'd say eventually you want all classes to fold up under the device directory (hence the parent pointer) and so be part of a continuous tree ... is that it?

Quoted 35 lines

It was one of the biggest mistakes to expose such a kernel implementation details as different entities to userspace, and one reason sysfs is that hard to understand. The guy who did all that just ran away leaving all this mess behind him. :) And yes, we are too slow cleaning all that up, but we will get there over time.


Quoted 2 lines

and not all interfaces are
fully flat.

True, but the core is only one flat tree, the drivers need to express "reverse trees" themselves, just like the raid block devices do.

Quoted 22 lines

Quoted 8 lines

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.

Quoted 5 lines

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?

There are still several problems with the symlink approach; not least of which is that the component namespace isn't globally unique, it's only unique to the enclosure: If you have two separate enclosures connected, they're likely each going to have a component called slot1 (the name is actually take from the enclosure). I also think we're going to have difficulty going back from a component to an enclosure, which was pretty much the whole point of the exercise but I need to get ses/enclosure actually working to look at that.

Quoted 4 lines

Hmm, I don't understand. The only thing that changed is that you don't have a core-managed "device" link at the enclosure component anymore, nothing else should be different. The namespace issue should be the same as it was before, right?

No, the way you broke it was removing the functioning component link.

If you boot now, all components are linked to the enclosure devices, not the component devices ... I can fix this easily, I'm still just trying to figure out how you want it represented.

Quoted 3 lines

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.

Quoted 9 lines · James Bottomley

Quoted 3 lines

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.

Quoted 2 lines

with a back link in the component device pointing to the enclosure component.

That sounds fine.

Quoted 2 lines

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?

Quoted 31 lines · Kay Sievers

Quoted 9 lines · James Bottomley

Quoted 3 lines

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.

Quoted 2 lines

with a back link in the component device pointing to the enclosure component.

That sounds fine.

Quoted 2 lines

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

Quoted 5 lines

...

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

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

So are we now all happy?

Quoted 42 lines · James Bottomley

Quoted 31 lines · Kay Sievers

Quoted 9 lines · James Bottomley

Quoted 3 lines

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.

Quoted 2 lines

with a back link in the component device pointing to the enclosure component.

That sounds fine.

Quoted 2 lines

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

Quoted 5 lines

...

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:

Quoted 13 lines

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?

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?

...

Quoted 11 lines

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

...

Quoted 1 line

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

I still slightly prefer cross link-names between the component and the LUN like "contains" -> and "enclosure" ->, but the current one should work too.

Quoted 57 lines · Kay Sievers

Quoted 42 lines · James Bottomley

Quoted 31 lines · Kay Sievers

Quoted 9 lines · James Bottomley

Quoted 3 lines

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.

Quoted 2 lines

with a back link in the component device pointing to the enclosure component.

That sounds fine.

Quoted 2 lines

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

Quoted 5 lines

...

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:

Quoted 13 lines

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

Quoted 3 lines

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.

Quoted 3 lines

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.

Quoted 14 lines

...

Quoted 11 lines

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

Quoted 2 lines

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.

Quoted 8 lines

...

Quoted 1 line

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.

Quoted 3 lines

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.

Quoted 1 line

It wasn't designed like this; an interface sits off to the side.

No, that's the way SCSI thinks it works, and unfortunately just duplicates real devices in the class directory. Class scsi_device- and scsi_host-devices are just 1:1 mirrors of the real bus devices. It just makes things far more complicated than needed. There is no such thing as "off the side interface" in the driver model or in sysfs, we just have "devices".

Since some releases. We talked about these plans and the way SCSI does it in person at FreedomHEC.
The driver model is just too complicated, we are cleaning that up step by step, and the completely inconsistent "class devices are interfaces" idea will completely go away. Sure, there will be symlinks preserving the old interfaces/behavior.

We talked about this extensively at LFS a few weeks ago. And Hannes gave a whole talk about that. What does a 1:1 mirror of the same device, other than having just doubled the number of devices, do good for us? Nothing but make it complicated to find information.

SCSI bus devices have functional attributes on their own, so it's completely inconsistent to split off _some_ of the functionality off to a second "mirror device" and call that an "interface".

We have a SCSI target and host in the /sys/devices/ tree already, there is no reason to mirror anything in a class scsi_device, same for the scsi_host. Really, that "interface to a device" idea must die, it never existed in the kernel code, only in some very confusing "documentation", which will be replaced pretty soon.

There will be no "device" link with any meaning with !SYSFS_DEPRECATED, only a single tree expressing _all_ core hierarchy, and flat classification symlinks (/sys/bus,class) to lookup the devices in the single device tree. In the end, there will be no bus or class device differences any userspace app would need to care about.

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.

I'm not sure I'm following all of the threads, but several of the points give me some concern. Bear with me if I'm off in the weeds (and I assume you'll straighten me out).

Quoted 8 lines

Quoted 1 line

It wasn't designed like this; an interface sits off to the side.

No, that's the way SCSI thinks it works, and unfortunately just duplicates real devices in the class directory. Class scsi_device- and scsi_host-devices are just 1:1 mirrors of the real bus devices. It just makes things far more complicated than needed. There is no such thing as "off the side interface" in the driver model or in sysfs, we just have "devices".

<ignoring the sas enclosure distinctions>

Is this discussion about removing the class device device object ? at least from the "class" directory and moving it into the /sys/devices tree ?

E.g.
Today, if I have a scsi hba, I have:
the scsi_host base device that is in the /sys/devices tree, which may then have 2 other objects, a scsi_host device for the /sys/class/scsi_host element and a fc_host device for the /sys/class/fc_host element. The base device in /sys/devices has 2 symlinks of the form <class>:<nm_relative_to_class>, and the /sys/class devices have a symlink, named "device" that points back to the base device in /sys/devices.

With the modification, you have:
the scsi_host base device that is in the /sys/devices tree, which then has 2 other devices underneath of it - one a scsi_host device (for the scsi_host class) and the other a fc_host device (for the fc_host class). The naming of <class>:<nm_relative_to_class> stays in the base device, but instead of being symlinks these are real directories for the sub-devices. Out in /sys/class, there is now a /sys/class/scsi_host/<nm1> that is a symlink back to the scsi_host class device, and similarly /sys/class/fc_host/<nm2> is a symlink back to the fc_host class device. And within the class devices, there is a "device" symlink to "..", mainly for compatibility ?

Did I follow this right ?

Quoted 6 lines

Since some releases. We talked about these plans and the way SCSI does it in person at FreedomHEC.
The driver model is just too complicated, we are cleaning that up step by step, and the completely inconsistent "class devices are interfaces" idea will completely go away. Sure, there will be symlinks preserving the old interfaces/behavior.

I'm confused... If what I described above is true, then yes, the class device become real devices, at least as far as there is only 1 device struct and its always linked under /sys/devices and there's never a "device" object off to the side for the class. But isn't there still an interface relationship to each of these device structures ? All this did was clean up where device structures live to a single place.

Quoted 9 lines

We talked about this extensively at LFS a few weeks ago. And Hannes gave a whole talk about that. What does a 1:1 mirror of the same device, other than having just doubled the number of devices, do good for us? Nothing but make it complicated to find information.

SCSI bus devices have functional attributes on their own, so it's completely inconsistent to split off _some_ of the functionality off to a second "mirror device" and call that an "interface".

Quoted 5 lines

We have a SCSI target and host in the /sys/devices/ tree already, there is no reason to mirror anything in a class scsi_device, same for the scsi_host. Really, that "interface to a device" idea must die, it never existed in the kernel code, only in some very confusing "documentation", which will be replaced pretty soon.

So, you are lobbying that we kill those devices for the class(es) and simply put all the different interface sysfs attributes on the base device ? If so, I'm concerned about attribute namespace overlap, and just a conglomeration of attributes on the base device. But I do like killing the other device structures.

Quoted 5 lines

There will be no "device" link with any meaning with !SYSFS_DEPRECATED, only a single tree expressing _all_ core hierarchy, and flat classification symlinks (/sys/bus,class) to lookup the devices in the single device tree. In the end, there will be no bus or class device differences any userspace app would need to care about.

which seems to jive with my description above, with the only exception that the "device" symlink only exists if SYSFS_DEPRECATED.

and from your other email thread :

Quoted 3 lines

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.

Well, the <classname> prefix came about because there was namespace overlap between different classes (e.g. scsi_host and fc_host classes use the same name, and I think where we originally saw this was in the way serial ports were enumerated for some base systems as well).

So I don't see how you can kill the <classname>:<devname> names by SYSFS_DEPRECATED.

Quoted 5 lines

Well, the <classname> prefix came about because there was namespace overlap between different classes (e.g. scsi_host and fc_host classes use the same name, and I think where we originally saw this was in the way serial ports were enumerated for some base systems as well).

Quoted 1 line

So I don't see how you can kill the <classname>:<devname> names by SYSFS_DEPRECATED.

With SYSFS_DEPRECATED, nothing will change. But these links don't exist with !SYSFS_DEPRECATED, because the class devices live in subdirectories, named after the class they come from, there is no namespace problem, or any problem to find these devices, you don't even need readdir() to look them up.

Quoted 8 lines · Kay Sievers

Quoted 8 lines

Well, the <classname> prefix came about because there was namespace overlap
between different classes (e.g. scsi_host and fc_host classes use the same name,
and I think where we originally saw this was in the way serial ports were enumerated
for some base systems as well).

Quoted 7 lines

Quoted 2 lines

So I don't see how you can kill the <classname>:<devname> names by SYSFS_DEPRECATED.

With SYSFS_DEPRECATED, nothing will change. But these links don't exist with !SYSFS_DEPRECATED, because the class devices live in subdirectories, named after the class they come from, there is no namespace problem, or any problem to find these devices, you don't even need readdir() to look them up.

Ok, it should have read :
I don't see how you can kill the <classname>:<devname> names w/
!SYSFS_DEPRECATED.

You still haven't answered my question about namespace overlap. What happens when the
device belongs to multiple classes, and the classes have the same name for the class
device ? I don't believe we ever want to be in the case where the classes
have to
understand a global namespace.

I take it you haven't even looked at how !SYSFS_DEPRECATED works today, have you? Try it and you will see that the namespace issue has been taken care of a long time ago :)

Quoted 3 lines · Greg KH

I take it you haven't even looked at how !SYSFS_DEPRECATED works today, have you? Try it and you will see that the namespace issue has been taken care of a long time ago :)

You are right... but I would assume it can be answered without pushing
someone back into the internals of the code to figure it out.

Quoted 7 lines · James Smart

Quoted 3 lines · Greg KH

I take it you haven't even looked at how !SYSFS_DEPRECATED works today, have you? Try it and you will see that the namespace issue has been taken care of a long time ago :)

You are right... but I would assume it can be answered without pushing
someone back into the internals of the code to figure it out.

Oh, I already answered it in an earlier mail :)
"these links don't exist with !SYSFS_DEPRECATED, because the
class devices live in subdirectories, named after the class they come from, there is no namespace problem"

This is how a LUN looks now:
tree /sys/devices/pci0000:00/0000:00:1d.7/usb5/5-1/5-1:1.0/host13/target13:0:0/13:0:0:0/ /sys/devices/pci0000:00/0000:00:1d.7/usb5/5-1/5-1:1.0/host13/target13:0:0/13:0:0:0/

  |-- block
  |   `-- sdb
  |       |-- subsystem -> ../../../../../../../../../../../class/block

  |       |-- sdb1
  |       |   |-- subsystem -> ../../../../../../../../../../../../class/block

  |       |-- sdb2
  |       |   |-- subsystem -> ../../../../../../../../../../../../class/block

  |-- bsg
  |   `-- 13:0:0:0
  |       |-- subsystem -> ../../../../../../../../../../../class/bsg

  |-- scsi_disk
  |   `-- 13:0:0:0
  |       |-- subsystem -> ../../../../../../../../../../../class/scsi_disk

  |-- scsi_generic
  |   `-- sg2
  |       |-- subsystem -> ../../../../../../../../../../../class/scsi_generic

Quoted 7 lines · Greg KH

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.

Quoted 5 lines

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.

Since the patch is separable, it's probably best to take it through the SCSI tree ... including the infiniband bits that depend on the iser/iscsi transport classes. You can give the rest of the infiniband pieces to roland, since he's got a nasty set of clashes with the __FUNCTION__->__func__ conversion which I don't want to be responsible for.

Quoted 19 lines · James Bottomley

Quoted 7 lines · Greg KH

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.

Quoted 5 lines

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.

Quoted 6 lines

Since the patch is separable, it's probably best to take it through the SCSI tree ... including the infiniband bits that depend on the iser/iscsi transport classes. You can give the rest of the infiniband pieces to roland, since he's got a nasty set of clashes with the __FUNCTION__->__func__ conversion which I don't want to be responsible for.

OK, I've changed my mind ... it doesn't really work well without all the rest of the pieces ... plus I think there are going to be merge nasties which I'd rather you sorted out.

What I'll do is run a scsi-post-merge-2.6 tree here:

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-post-merge-2.6.git;a=summary

I've dropped a quasi stable branch from your quilt tree and plumbed it into the -mc tree generation machinery, so it will warn me if you make too radical an alteration to your quilt.

Quoted 27 lines · James Bottomley

Quoted 25 lines · James Bottomley

Quoted 7 lines · Greg KH

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.

Quoted 5 lines

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.

Since the patch is separable, it's probably best to take it through the SCSI tree ... including the infiniband bits that depend on the iser/iscsi transport classes. You can give the rest of the infiniband pieces to roland, since he's got a nasty set of clashes with the __FUNCTION__->__func__ conversion which I don't want to be responsible for.

Quoted 3 lines

OK, I've changed my mind ... it doesn't really work well without all the rest of the pieces ... plus I think there are going to be merge nasties which I'd rather you sorted out.

Ok, so what do you want me to do?

I can keep the scsi patch and the IB
patches in my tree and merge them that way, but I think it causes problems with your scsi patches. That will cause the -next and -mm tree issues, right?

Quoted 7 lines

What I'll do is run a scsi-post-merge-2.6 tree here:

http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-post-merge-2.6.git;a=summary

I've dropped a quasi stable branch from your quilt tree and plumbed it into the -mc tree generation machinery, so it will warn me if you make too radical an alteration to your quilt.

So I shouldn't drop the patch from my tree?