Kay, James,
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).
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 ?
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.
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.
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.
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 :
> 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.
-- 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
