On Thu, Oct 05, 2006 at 10:21:22AM -0400, Alan Stern wrote: > 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!
<snip example> Yeah, this has been known for some time without any solution :( Although it isn't usually as bad as you think, as the module is still pinned in memory when the file is open, so the code doesn't go away. But yeah, the pointer back to the usb_device could be stale and things still go boom that way. > 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. But how will the removal of the sub_device help with the fact that userspace could still have the file open? I like the general sound of the idea, just don't know how it would solve the private data issue from going stale. thanks, greg k-h ------------------------------------------------------------------------- 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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
