Hi<br><br>There's essentially 2 ways USB could work in Wine[1]:<br><br>1. Process per driver, but special-case loading and initializing USBD.SYS<br>Like my previous patchset:<br><a href="http://www.winehq.org/pipermail/wine-patches/2010-November/095883.html">http://www.winehq.org/pipermail/wine-patches/2010-November/095883.html</a><br>
<a href="http://www.winehq.org/pipermail/wine-patches/2010-November/095884.html">http://www.winehq.org/pipermail/wine-patches/2010-November/095884.html</a><br><br>2. Dedicated process for USB, in which USBD.SYS loads first, and it loads USB device drivers (possibly > 1) into the same process as the need arises.<br>
<br>What's the right way? Which approach is going to get my patches accepted?<br><br>Thank you<br>Damjan<br><br>[1] Because the steps are as follows:<br>1. USB device is plugged in<br>2. USB hub driver looks up the driver based on the device class/vendor/product IDs<br>
3. The device driver gets loaded and DriverEntry() gets called on it<br>4. AddDevice() gets called on the driver, specifying the device<br>5. Only then, the driver calls things lower in the stack, to do USB I/O<br><br>The driver needn't load any other driver in its DLL import table, and even if it did, drivers loaded through the import table don't have their DriverEntry() called, so they cannot do anything on load. Even if we rely on most USB drivers loading USBD.SYS, USBD.SYS needs to do steps 1-4 first, but it wouldn't have control passed to it until step 5, hence it can't ever do anything. The only way out is one of the following:<br>
1. Process-per-driver, but when a driver loads USBD.SYS, USBD.SYS is special-cased by winedevice, ie. it has a special export called on it at load which specifies the other driver and gives it a chance to create a separate thread for steps 1-4.<br>
2. Dedicated process for USB, in which USBD.SYS loads first, and it loads USB device drivers (possibly > 1) into the same process as the need arises.<br><br>