On Wed Jun 28 09:46:40 2023 +0000, Zebediah Figura wrote:
I took the liberty of writing some ntoskrnl-based tests: https://testbot.winehq.org/JobDetails.pl?Key=133935 The conclusions that one can apparently draw are:
- Buffered ioctls pass through zero, for both the pointer and size, if
either the pointer or the size is zero. This basically contradicts Alexandre's original feedback—at least for buffered ioctls, that really is what's supposed to happen.
- Buffered ioctls return STATUS_ACCESS_VIOLATION if the buffer pointer
and size are nonzero but invalid. This is done somewhere in the NT kernel.
- Direct ioctls behave similarly, with the exception that a NULL output
buffer is *not* treated as not-specified.
- Neither ioctls simply pass through their parameters without modification.
In order to exactly emulate this behaviour for NEITHER ioctls, we will need extra flags (in order to signal to the Unix side whether the ioctl was originally NULL or not). On the other hand, NEITHER ioctls are kind of generally tetchy. I suspect that the right thing to do is something close to the original patch, possibly limited to buffered ioctls.
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.
I added at least temporary your test here as a draft.
Your test contains assignments for the direct ioctls (8833c709). Are these intentional or should they get removed?
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?
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?