On Mon, 2009-11-02 at 13:11 -0800, Matthew Dharm wrote: > On Mon, Nov 02, 2009 at 12:18:35PM -0800, Dan Williams wrote: > > Devices with fake driver CDs and how they are handled currently: > > > > Zydas WLAN - kernel > > Huawei 3G - kernel (unusual_devs entry) > > Sierra 3G - kernel (drivers/usb/serial/sierra.c) > > Option 3G - udev rules, 'rezero', or usb_modeswitch > > ZTE 3G - udev rules, simple 'eject' > > It's worth noting that for some of these which are handled in-kernel, it > had to be done that way because their storage-emulation was so poor that > the normal 'eject' WOULD NOT work properly. Half of them don't use eject at all, because of course on Windows the vendor driver owns the device and can do whatever it wants. Huawei uses a custom sequence, Option uses a custom sequence, and so does Sierra. ZTE is the only one that I've seen that you can actually just "eject" and make it work. In userspace, usb_modeswitch is the place to put all this logic. Then you tie it together with udev rules using some bubble-gum and duct-tape, and maybe it works. Of course, there's massive duplication of data between usb_modeswitch and the kernel drivers, because the there's simply no communication between the two. The kernel drivers know which devices are supported and how to drive them. But because the eject code isn't in kernelspace, all that device selection logic has to be duplicated in userspace with usb_modeswitch. Pretty dumb. Maybe we can get the kernel drivers to expose the information we need (maybe even an 'eject' attribute in sysfs or something) and then we just have to write udev rules instead of having a whole bunch of libusb junk in userspace? Would that preserve the policy-always-in-userspace requirement yet keep the code to drive the hardware in kernel space where it really belongs? Dan -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
