On Wed, 4 Oct 2006, Greg KH wrote:
> > > If you think you want an easy way to find all usb hubs in the system,
> > > and /sys/bus/usb/drivers/hub/ isn't good enough for it, then yes, a
> > > class could work.
> >
> > In this case I guess a class isn't really needed.
>
> I agree.
Well, a little more thought has revealed a problem. Namely:
It's not safe for a driver to create an attribute file in
a sysfs directory unless the driver also owns the directory!
For example, let's say the parent driver P has detected a new hotplugged
device X and has registered the struct device for X. The child driver C
is bound to X and creates its own private data structure. Suppose C
creates an attribute file for X. What happens later on when C is unbound
from X?
There may still be open file references to the attribute and userspace can
still access them, causing callbacks to C and passing a pointer to X's
struct device. Now what can C do? The private data structure is gone,
and C isn't allowed to access X's struct device any more because it is
unbound.
The problem arises because the attribute callback passes a pointer to X's
struct device instead of C's private data structure, and C doesn't control
the X struct device -- P does.
(In the case at hand, of course P is usbcore, C is the hub driver, and X
is the hub interface. Don't try to confuse the issue by pointing out
that the hub driver is built into usbcore; logically they are separate.)
For this to work, C needs more control. One possibility is to stick the
attribute in a class_device directory; since C creates and destroys the
class_device everything is okay. But this means adding all the overhead
of a new class and still doesn't allow the attribute to sit in the
original device directory.
Here's an alternative approach. Define struct sub_device as a sort of
lightweight struct device. It won't have most of the supporting
infrastructure, not even an embedded kobject; it's only purpose will be to
hold attribute files. These files will show up in the directory of the
sub_device's parent device.
That way C can create and destroy the sub_device as needed, typically by
embedding it within the private data structure. Even though the attribute
files will show up in the original device directory, the callbacks will
receive a pointer to the sub_device structure, and so C will have total
control.
What do you think of this idea?
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
