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

James Smart
2008-03-17T04:15:38Z

Kay Sievers wrote:
>> 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.
>
> 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 know this exists a couple of places, because it's what drove us to using the "<class_nm>:"
prefix in the beginning. Additionally, I know of several utilities that found a lot
of benefit to having the class name. For example, the different transports in scsi all
use the same names for their devices, which overlap with the scsi_host name. The utility
could use the prefix to understand what class the device belonged to. What do you have
to replace this with ? - a symlink to the /sys/class symlink ? a pattern matching on
what attributes exist (and optional attributes make this ugly) ? a new sysfs attributes
in the object, say class, that spits out the class name ?
Keeping the prefix may also be useful to distinguish between class devices and real
child devices.

-- james s