I have spent this week on improvements of realization and done stability fixes in usbhub PDO/FDO.
I have prepared usbhub FDO's handling of removal and surprise-removal IRPs. We'll receive surprise-removal IRP on HUB unexpected removal, or on USB controller removal from PCI port. Here hub should "let know" all its children that their parent is removed and on next removal they also can be removed. For now this code path can't be tested because none of our host controllers can be removed now(they are failing query remove). But surely I must fill all cases to go forward and not get back to this later. Related to removal-IRP, now it is ready to work.
Is there anything more important than safety of our children?
I have added synchronization for FDO's child list access. As FDO's child list is getting changed not from PnP dispatcher but from DeviceStatusChangeThread(), we need to synchronize access for it. For this at first turn I have used spinlock, but then I have found that there is more preferable guarded mutex because in some code paths it requires be in PASSIVE_LEVEL which is impossible with spinlock held. So now our usbhub FDO's child list is safe place for its children ^_^ .
Also I've added PnP state tracking for FDO/PDO sides. This is done to make our codes more understandible and also to increase safety of code. Implementation is done like in MS's sample bus drivers.
Let's make our code a learning place.
Some of described above is already pushed to my github, but also there is codes for which I haven't created commits yet. As you may see in my repo, all my commits are documented, and that’s requires some time to prepare well documented commits. As I mentioned before, for me well documentation of commits and commenting of code is the first priority in contribution to open source projects. Because this type of projects is also learning point for programmers of all ranks.