Message-ID: <4E44D5B5.7040305@redhat.com>
Date:	Fri, 12 Aug 2011 09:26:45 +0200
From:	Hans de Goede <hdegoede@...hat.com>
To:	Alan Stern <stern@...land.harvard.edu>
CC:	Theodore Kilgore <kilgota@...ach.math.auburn.edu>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	Greg KH <greg@...ah.com>,
	Mauro Carvalho Chehab <mchehab@...radead.org>,
	linux-usb@...r.kernel.org, linux-media@...r.kernel.org,
	linux-kernel@...r.kernel.org, libusb-devel@...ts.sourceforge.net,
	Alexander Graf <agraf@...e.de>,
	Gerd Hoffmann <kraxel@...hat.com>, hector@...cansoft.com,
	Jan Kiszka <jan.kiszka@...mens.com>,
	Stefan Hajnoczi <stefanha@...ux.vnet.ibm.com>,
	pbonzini@...hat.com, Anthony Liguori <aliguori@...ibm.com>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Oliver Neukum <oliver@...kum.org>, Felipe Balbi <balbi@...com>,
	Clemens Ladisch <clemens@...isch.de>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Adam Baker <linux@...er-net.org.uk>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists