Damjan Jovanovic damjan.jov@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.