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