lkml.org 
[lkml]   [2011]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: USB mini-summit at LinuxCon Vancouver
    Hi,

    On 08/05/2011 12:56 AM, Greg KH wrote:
    > On Thu, Aug 04, 2011 at 07:21:47PM -0300, Mauro Carvalho Chehab wrote:
    >> I know that this problem were somewhat solved for 3G modems, with the usage
    >> of the userspace problem usb_modeswitch, and with some quirks for the USB
    >> storage driver, but I'm not sure if such tricks will scale forever, as more
    >> functions are seen on some USB devices.
    >
    > Well, no matter how it "scales" it needs to be done in userspace, like
    > usb_modeswitch does. We made that decision a while ago, and it is
    > working out very well. I see no reason why you can't do it in userspace
    > as well as that is the easiest place to control this type of thing.
    >
    > I thought we had a long discussion about this topic a while ago and came
    > to this very conclusion. Or am I mistaken?

    I think we've had multiple discussions about this, surrounding various
    topics / use cases. I would not call the do it in userspace a conclusion.

    I rather more have a feeling of getting stonewalled on this by various people
    surrounding the usb system. Me shutting up on this is basically a case of:
    "Discussion not getting anywhere and I don't have the time to do a kernel
    proof of concept myself right now".

    To be clear about the stonewalling I'm not talking about the dual cam issue
    here, nor about the morphing devices thing which usb_modeswitch fixes.

    I think it is important to separate oranges from apples here, there are
    at least 3 different problem classes which all seem to have gotten thrown
    onto a pile here:

    1) The reason Mauro suggested having some discussion on this at the
    USB summit is because of a discussion about dual mode cameras on the
    linux media list. Dual-mode cameras are (usually very cheap) digital
    photo cameras which can take still pictures in stand alone mode and
    store them in onboard memory, like regular digital photo cameras, this
    is one mode. The other mode is they can operate as a regular webcam,
    the hardware actually is more regular webcam hardware with some memory
    and a battery added (usually no viewfinder screen).

    These devices typically use 1 usb interface (and thus 1 driver) for
    both modes. We currently have drivers for both modes, but they are
    separate drivers, which leads to fighting for device ownership,
    with the stillmode driver always winning as that is userspace and
    it simply kicks of the kernel webcam /streaming mode driver making
    it see a device unplug, even if an app was streaming from the device
    at the time. The solution here is simple, move both functions to
    1 driver, which can then properly return -EBUSY when the device
    is active in one mode and an app tries to use it in the other mode.

    This 1 driver will likely end up being a kernel driver, since doing
    streaming drivers in userspace is problematic, as the v4l2 API assumes
    a kernel device node, and we don't want to invent a new API, we want
    something which works with existing applications.

    2) So called morphing devices. For example a USB 3G modem which
    initially shows up as a cdrom drive with windows software, only
    to reveal its real identity (with completely different usb
    descriptors) after some magic command. This is solved by the
    usb_modeswitch command, nothing to see here move along.

    3) Re-direction of usb devices to virtual machines. This works by using
    the userspace usbfs interface from qemu / vmware / virtualbox / whatever.
    The basics of this work fine, but it lacks proper locking / safeguards
    for when a vm takes over a usb device from the in kernel driver.

    Example of the problem: usb mass storage devices is mounted, filesystem
    is in use and dirty, with writebacks pending, user redirects to vm,
    usb mass storage driver sees the cable beeing yanked out of the device.

    Now we've lost the pending writebacks and have a dirty, if not journaling
    possibly corrupt, fs on the device.

    This is the issue on which I feel a bit stonewalled. Simple putting your
    fingers in your ears and singing la la la do it in userspace is not going
    to cut it here. There is no way to do this race free in userspace, unless
    all possible callers of mount get modified. Moreover 99% of the necessary
    accounting for this is already done in the kernel. We already have the notion
    of a block device being in use. We simply need to add some code to pass
    this notion to the usb mass storage driver, and add a new try_disconnect
    callback for usb drivers. I'm not saying this is going to be completely
    straight forward, but it ain't rocket science either. And it so very
    obviously is the *right* thing to do, that I'm getting very tired of
    the do it in userspace song I keep hearing.

    Regards,

    Hans


    \
     
     \ /
      Last update: 2011-08-05 09:47    [W:0.025 / U:32.496 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site