Messages in this thread | | | Date | Thu, 19 Jun 2003 09:42:57 -0700 (PDT) | From | Patrick Mochel <> | Subject | Re: Flaw in the driver-model implementation of attributes |
| |
> > Ok, have you _read_ the documentation on the driver model? In it, > > classes and devices are clearly spelled out as to what the differences > > are, and what shows up where. > > Yes, of course I've read it. It's lacking a number of important details.
Hey, we've tried. I realize it's missing details, and though I know it's important to keep it updated, many other things take precedence.
> For example, nowhere in devices.txt does it say that a device driver > should not create attributes in the struct device's directory since that > directory is owned by the bus driver. (That's a very easy mistake to > make; at first sight it appears to be the natural way for a driver to > expose details of how it controls a device.) In fact, nowhere in the > documentation does it say that you shouldn't attach an attribute to an > object unless you own that object. Maybe that seems obvious, but when a > driver is bound to a device can't it be said to "own" that device in some > sense?
It's "bound" to the device, but it does not own the object.
Note that only recently have we realized the full importance of creating attributes _only_ for objects that you own. It's exposed bugs recently, and hasn't had a chance to make it in to the documentation.
> Let me ask you this: Given a device that doesn't fit clearly into any of > the existing classes, how would you decide whether or not to create a new > class for it?
If it does not fit into the existing classes, then there is probably a new class that needs to be created for it. While you're at it, please update the documentation and set a good example for the rest of us ;)
> Yes, but _which_ physical things correspond to devices? And how should > the parent-child relationships be decided? > > Consider a concrete example: a USB host controller. Let's say that on my > system /sys/devices/pci0/0000:00:07.2 is an OHCI HC. That particular > object is created by the PCI bus driver, and directly below it is > /sys/devices/pci0/0000:00:07.2/usb1 -- what physical thing does that > correspond to? Is it the virtual root hub? It's created by the USB core; > where does the object created by the HC driver belong? > > Or have I misunderstood, and was it intended from the start that _all_ the > objects under /sys/devices/ should be created by bus drivers, while _all_ > the objects created by device drivers belong somewhere else?
Yes.
> Is that > somewhere else always under /sys/class/ (or /sys/block/)?
Yes, /sys/class
> And where in > the documentation is this spelled out?
It should be in the first sections of each driver model paper - The hierarchy under /sys/devices/ represents the physical hierarchy of the system itself. Each object represented in it is intended to map directly to a physical device. Physical devices are discovered and registered by bus drivers in the system.
-pat
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |