lkml.org 
[lkml]   [2003]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:36    [W:0.053 / U:0.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site