On Tue, 30 Aug 2005, Daniel Ritz wrote: > if i didn't miss anything usb's check for knode_bus is also stupid workaround > to avoid a double device_bind_driver()...
That's not really right. The actual reason usb_driver_claim_interface calls klist_node_attached is to avoid calling device_bind_driver for a device that hasn't been registered yet. It's not meant for avoiding double binds (and in fact it won't prevent them). Similarly, the test in usb_driver_release_interface is to avoid calling device_release_driver for a device that hasn't been registered yet. > > Have I missed something here? Since when has the .driver member been > > removed from usb_interface? > > > > 18 months ago. see: > http://linux.bkbits.net:8080/linux-2.6/diffs/drivers/usb/core/usb.c%401.157?nav=index.html|src/.|src/drivers|src/drivers/usb|src/drivers/usb/core|hist/drivers/usb/core/usb.c That patch didn't remove any fields from any structures. > but i still think it's damn ugly to check for knode_bus (layering violation?) I agree. The other patch I've been working on adds a new routine to include/linux/device.h: +static inline int +device_is_registered (struct device *dev) +{ + return klist_node_attached(&dev->knode_bus); +} At least it makes things look more logical. > besides: usbaudio (and others) calls usb_driver_claim_interface() for the > second > interface but does not own intf2->dev.sem It's okay because they do own the private USB semaphore for the overall device. That's mentioned explicitly in the kerneldoc. > it's just because i kinda agree with christoph hellwig about the klists. > > they don't buy us anything but give overhead for nothing. each klist_node > points to the list head but for nothing. we already have the refrerence to > the parent device, bus, driver or whatever. it's just ugly if you ask me. > (with almost no users, one less with your patch) The one advantage of klists is that they allow a thread to add or remove nodes while another thread iterates through the list. The alternative is to make the list single-user (like my patch does for the driver's devlist) or to protect it with an rwsem. The current state of things is a reaction against the old bus subsystem's rwsem, which protected too much. I wouldn't object to replacing klists with a per-list rwsem. But I don't know how Greg KH or Pat Mochel might feel about it. > > I know the requirements for USB but not for those other subsystems. > > Talking with their maintainers may help. In some cases the interfaces can > > be simplified now that manual driver binding is available through sysfs. > > > > i guess the most important is the one from dimitry. not deadlocking. > > so i think your patch is a good start to work from. Thanks. Alan Stern ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
