Damjan Jovanovic <damjan....@gmail.com> writes: > I've hacked at this enough to get some basic USB I/O working, so now I > have a better idea of what's necessary. > > I like usbhub.sys separate from usbd.sys because: > * The service is called Usbhub in the registry, drivers might depend > on the service, and having the service load usbd.sys instead of > usbhub.sys is confusing. > * usbd.sys isn't part of the device stack in any way, it's just a > utility library used to do miscellaneous things like parse USB > descriptors. Putting I/O code in there would be confusing. > * Windows from 2000 onwards uses usbhub.sys for device stack > management and I/O. No Windows version uses usbd.sys like that. > * If we don't want dlls that export nothing, mountmgr.sys also exports > nothing, so it should be part of ntoskrnl.exe by the same logic. > * There will no more usbXXX.sys files for basic USB after usbhub.sys. > We might eventually want higher-level device class drivers > (usbstor.sys, usbprint.sys) and Microsoft-provided generic drivers > (usbscan.sys) though. > * The driver doesn't load first and load usbd.sys via an import which > creates a device stack, usbhub.sys loads first and then loads drivers > (into the same process) on-demand, as their USB devices are plugged > in. > > A *very hacked* patch is attached, if you want to see how libusb-1.0 > is used. It only works just enough for the driver to read descriptors > from the device and send a few basic I/O requests. > > I'd like to start sending real patches soon, so can I add a separate > usbhub.sys or do I have to stick with usbd.sys? And is libusb-1.0 ok?
It seems to me that the device detection needs to be handled by mountmgr, you don't want a libusb polling loop. Also I don't think you want to load all of usb inside the same process, native drivers will crash, and that shouldn't take down the whole usb support. I'd say you should have one process per device or something along those lines. -- Alexandre Julliard julli...@winehq.org
