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/