Messages in this thread | | | Date | Fri, 12 Aug 2011 09:26:45 +0200 | From | Hans de Goede <> | Subject | Re: USB mini-summit at LinuxCon Vancouver |
| |
Hi,
On 08/11/2011 04:56 PM, Alan Stern wrote: > On Thu, 11 Aug 2011, Hans de Goede wrote: > >>> The alternative seems to be to define a device-sharing protocol for USB >>> drivers. Kernel drivers would implement a new callback (asking them to >>> give up control of the device), and usbfs would implement new ioctls by >>> which a program could ask for and relinquish control of a device. The >>> amount of rewriting needed would be relatively small. >>> >>> A few loose ends would remain, such as how to handle suspends, resumes, >>> resets, and disconnects. Assuming usbfs is the only driver that will >>> want to share a device in this way, we could handle them. >>> >>> Hans, what do you think? >>> >> >> First of all thanks for the constructive input! >> >> When you say: "device-sharing protocol", do you mean 2 drivers been >> attached, but only 1 being active. Or just some additional glue to make >> hand-over between them work better? > > I was thinking that the webcam driver would always be attached, but > from time to time usbfs would ask to use the device. When the webcam > driver gives away control, it remains bound to the device but does not > send any URBs. If it needs to send an URB, first it has to ask usbfs > to give control back. >
Oh, interesting...
<snip lots of good stuff>
> I'm not claiming that this is a better solution than putting everything > in the kernel. Just that it is a workable alternative which would > involve a lot less coding.
This is definitely an interesting proposal, something to think about ...
I have 2 concerns wrt this approach:
1) It feels less clean then just having a single driver; and 2) I agree it will be less coding, but I doubt it will really be that much less work. It will likely need less new code (but a lot can be more or less copy pasted), but it will need changes across a wider array of subsystems / userspace components, requiring a lot of coordinating, getting patches merged in different projects, etc. So in the end I think it too will be quite a bit of work.
I guess that what I'm trying to say here is, that if we are going to spend a significant amount of time on this, we might just as well go for the best solution we can come up with even if that is some more work.
Regards,
Hans
| |