Thank you very much for spending your time. I would not have gotten the idea to look at this interface from the driver side or defining own ioctls.
No problem, I was curious :-)
Your test contains assignments for the direct ioctls (8833c709). Are these intentional or should they get removed?
IIRC those were intentional. As you've noticed I didn't quite fully clean up the tests. I think what I encountered was that if the user address was NULL, then the system would actually pass a NULL pointer instead of a real MDL (to a NULL pointer). It does make the names "input_buffer" / "output_buffer" slightly misleading, though.
Basically with e93bf711 and 9c0974ce the buffered and direct tests would succeed. Like you wrote to support the neither ioctls it would take more.
Should I still limit this MR to just the buffered ioctls?
Since the direct tests look easy that seems reasonable to include here.
And should your test go into wine? If yes how can I properly add your authorship? Is then the specific IOCTL_STORAGE_GET_DEVICE_NUMBER test still needed?
Yes, probably, though as mentioned it may need a bit of cleaning up.
You can probably fix the authorship by amending it with something like
git commit --amend --no-edit --author="Zebediah Figura zfigura@codeweavers.com"
The tests I wrote are comprehensive, but it does have the disadvantage that it will only run on the testbot machines configured to support ntoskrnl tests, so keeping the other tests may be a good idea.