On Mon, May 04, 2009 at 01:05:09PM -0700, Steve Calfee wrote:
> On Mon, May 4, 2009 at 11:35 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
> > On Mon, 4 May 2009, Pantelis Koukousoulas wrote:
> >
> >> Anyway, I 'd prefer to have the possibility to assign only a
> >> few ports/hubs to userspace and keep the rest functioning
> >> normally, as long as this doesn't cause significant trouble elsewhere.
> >
> > I can understand that; it makes sense.
> >
> >> So, the first step in the process would be a userspace
> >> program claiming one or more ports/hubs or a wildcard
> >> "everything" from the kernel, right?
> >
> > Yes. It's not obvious what would be a good API for doing this.
> >
> As I see it this is the problem.
>
> We already have a good user space solution for handling driver loading
> and handling devices -- udev.
>
> The problem is that we have another scheme for allocating drivers to
> devices via driver probe routines. When a new device is discovered the
> kernel tries to allocate devices to drivers by a first registered gets
> first claim on a device. This is done independently of udev. Having
> this kernel based method of device to driver mapping makes sense if
> there is no udev and a module is already loaded -- known devices get
> allocated to drivers.
>
> The conflict is painful with the many broken (Windows tested only)
> devices.
Really?
> Perfectly USB legal bus sequences hang/kill many devices.
What types of devices? Bug report pointers somewhere?
> If an emulator system (qemu, vmware,...) has an OS driver that knows
> exactly how to coddle the broken device, there is currently no known
> way to not have the kernel NOT break the device (doing perfectly legal
> USB transfers).
>
> The only solution I see is to have the USB probing stuff be modal -
> either the kernel is in control of everything or udev is. I hate modal
> interfaces, it is a pain to determine which mode a system is in,
> double the debug issues etc, but I see no alternative for the
> emulation, remote USB (usb-ip) problems.
udev isn't in "control" of anything. It passes all "hey I see a new
device" messages off to modprobe, which then does the device matching
and tries to load a new driver if possible.
Then the kernel does the real matching and attaching drivers to devices.
> When udev is in charge it should handle driver installation and device
> probing. When the kernel is in charge udev can do as it does now, but
> the kernel will handle probing. This allows embedded systems and boot
> time device handling to go on as now.
>
> Ideally, multiple (root level emulator created) udev scripts could
> simultaneously handle multiple "owners" of devices, both locally and
> (multiple) virtual operating systems.
Ick, no.
You all seem to be spinning downward from what the original
proposal/goal here was:
- create a new "top level" usb driver and register it with the kernel.
- this driver grabs any devices seen and then can decide if it really
wants to control it.
- if not, hand it back to the kernel with the standard "I can't
control this device" error, and then the standard Linux USB "top
level" driver takes over like today.
It's really not that complex, please don't make it out to be much more
than is really necessary here.
And yes, this will require a in-kernel Linux driver, which is why vmware
has not done this, because of the licensing issues involved that they
seem to want to ignore/avoid/piss on.
But kvm/qemu can do this, so it shouldn't be an issue.
Also, you might want to look into the usb-ip interface, that might be
sufficient for what you are doing, I know it is what a lot of KVM
instances use today.
Hope this helps,
greg k-h
--
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
