Re: USB mini-summit at LinuxCon Vancouver

[Hans de Goede]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/