On Wed, Mar 30, 2005 at 08:32:44PM +0200, Kay Sievers wrote:
> On Thu, 2005-03-17 at 09:53 -0500, James Bottomley wrote:
> > On Wed, 2005-03-16 at 14:45 -0800, Patrick Mansfield wrote:
> > > Any comments on this? Should I resend these patches?
> >
> > Well, the basic comment is that there are a lot of features that SCSI
> > has that the driver core lacks:
> >
> > 1) Attribute overrides. This is actually part of the published API for SCSI
>
> What does this exactly mean? Handle the same attribute dynamically with
> a different source of data?
Well a different function handled by the host driver, rather than the
function in scsi core, for example, the twa_queue_depth_attr in
drivers/scsi/3w-9xxx.c overrides the simple read attr function in
scsi_syfs.c created via this line:
sdev_rd_attr (queue_depth, "%d\n").
The patch left this in but only for queue_depth, not for all of the
scsi_devie attributes. We have sht->change_queue_depth that can already
handle this, some drivers use it, but some still use the sdev_attrs to
override the queue_depth. IMO, we should get rid of the override, James
doesn't agree.
James - are you OK with allowing only specific overrides of attributes?
> > 2) Ability to add extra attributes---several drivers use this
>
> What is missing in the driver core here? Why can't you add/remove
> attribute files at any time?
The patch left this alone, but should be changed to make sure duplicate
(that we can't override) attributes get errors. It is just a nice way for
host adapters to add attributes to a scsi_device.
But, for any of these non bus_attr and class attributes, the hotplug
notification (for scsi_device or the upper level block/char device) will
still come before the attributes are created. This is also true for the
transport attributes. This is a potential problem, I know of no udev
program or hotplug helpers that use any of these attributes.
I see no easy way around this problem without a multi-step registration,
like a device_init(), device_ready(). So a device_add would just be:
device_init()
device_ready()
Is your kobject_hotplug patch still pending?
We also need the following, else dev_attrs will show up after the probe
and hotplug event for a matching driver (for example, an sd block hotplug
event is generated via the device_attach() call). This could be causing
problems today, AFAIR you already hack around this problem in udev.
--- bleed-2.5/drivers/base/orig-bus.c Tue Mar 15 17:08:18 2005
+++ bleed-2.5/drivers/base/bus.c Wed Mar 30 10:48:34 2005
@@ -458,14 +458,14 @@ int bus_add_device(struct device * dev)
int error = 0;
if (bus) {
+ device_add_attrs(bus, dev);
+ sysfs_create_link(&bus->devices.kobj, &dev->kobj, dev->bus_id);
+ sysfs_create_link(&dev->kobj, &dev->bus->subsys.kset.kobj,
"bus");
down_write(&dev->bus->subsys.rwsem);
pr_debug("bus %s: add device %s\n", bus->name, dev->bus_id);
list_add_tail(&dev->bus_list, &dev->bus->devices.list);
device_attach(dev);
up_write(&dev->bus->subsys.rwsem);
- device_add_attrs(bus, dev);
- sysfs_create_link(&bus->devices.kobj, &dev->kobj, dev->bus_id);
- sysfs_create_link(&dev->kobj, &dev->bus->subsys.kset.kobj,
"bus");
}
return error;
}
-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
