On Tue, 5 May 2009, Pantelis Koukousoulas wrote: > > 1. Some devices shouldn't be configured by the kernel's generic > > driver. For one reason or another, they need to be put in a > > specific config, or they can't handle having the config > > changed once it has been set. > > > > 2. A userspace program that wants a high degree of control over > > a device finds changing configs rather difficult. First it > > has to release all the interfaces, then do the actual > > Set-Config, then claim all the new interfaces. This is > > failure prone and doesn't prevent kernel drivers from > > binding to and messing up the new interfaces. If any of the > > old interfaces were in an altsetting higher than 0, the > > kernel will put them back in altsetting 0 when the interface > > is released -- not what we want to happen. > > > > 3. Userspace programs that want a high degree of control over > > a device always have to worry about the possibility that > > a different program might interfere via usbfs or sysfs. > > We are in 100% agreement regarding where the problems are :) Are we? Steve's email seemed to indicate that he may have some different ideas. > > The API for claiming and releasing ports needs to be determined; > > everything else seems fairly straightforward. I'm open to suggestions; > > the biggest requirement is that when a program ends, all its ports have > > to be released automatically. This suggests using some sort of control > > file for the API. > > Yep, we don't want a buggy program taking our ports with it to its doom :) Taking the ports to its doom would be okay. I don't want a program taking the ports _beyond_ its doom, thereby removing any possibility of ever releasing them. > So, it seems to me that we are all on the same page about what needs > to be done and also agree about the overview of how (new driver probed > before generic, some sort of file-based grabbing, etc). I'm open to suggestions for how the file-based grabbing should be implemented. Not to mention some unsettled issues, like what should happen if a program grabs a port and another program has already claimed an interface on the device attached to that port. Or if another program simply has the device file open. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
