On Sun, 2008-03-16 at 16:21 -0400, James Smart wrote: > 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 ? The directories move to /sys/devices, /sys/class is functionally the same, but only a bunch of symlinks pointing to the devices instead of real directories. > 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. The class devices needed to be connected to their bus parents by the "<class>:<name>" link and the "device" link, yes. This became a real mess when people tried to put hierarchies between class devices. So we deprecated the "lots of disconnected trees spread around" model, and moved all into a single tree, with proper device DEVPATH's, which include all the parent dependencies, for the 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 ? The class devices appear where they belong, below their parents. In the /sys/class directories will be only symlinks. The "<class>:<name>" links are gone. The "device" link is not needed, it's just the next parent device. It is still created at the moment, but will go away some day. > 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. All devices live in /sys/devices/, all the rest is symlinks. All devices will continue to exist, have the same names and attributes, and will still looks the same, just all in one single hierarchy. The /sys/class/ directory will on be a classification directory to lookup devices in the tree, just like /sys/bus/*/devices/ was forever. > > 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. Only the 1:1 duplicated devices, both refcounted objects embedded in the same scsi struct, like scsi_device and scsi_host. We should move the attributes to the real device, and create a symlink at the old place, there is no need for two device directories for the same thing. > > 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. It still exists in both cases, but it will go away some day. > 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. 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. Thanks, Kay -- 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
