> Why not do the mode switch from userspace? I thought we were trying to move all the mode-switching stuff in that direction..... I need to tie in to the main USB mass storage driver in a way that I think would make it too complicated to move the mode switching part to userspace. See the part I'm adding to initializers.c... that one has to be in the kernel since it operates on the device after the mode switch when it is claimed by the normal USB storage driver. But the mode switch part has to communicate information to it to make sure it picks up the right device (just relying on the normal USB device matching isn't enough in this case, because all Android devices in AOA mode identify themselves with that well-known VID/PID... I don't know if there's any other kernel driver using this protocol today, but there may be at some point and then it becomes important to make sure you really grab the device you meant to grab). Some of that information (the 'route' field) isn't even directly available from userspace (I could use the device name string instead and that would roughly come out to the same thing, but seems less clean to me). So I could either do the mode switch in userspace and add a big custom sysfs interface to the usb-storage driver to allow userspace to configure all this, or I can add a small kernel shim driver like in this patch. Considering how little code the shim driver actually needs I expect it would come out to roughly the same amount of kernel code in both cases, and I feel like this version is much simpler to follow and fits cleaner in the existing "unusual device" driver infrastructure.
