On 6/4/21 11:12 AM, Rémi Bernon wrote:
Signed-off-by: Rémi Bernon rbernon@codeweavers.com
v3: Minor changes, drop the controversial test fixups, let's ignore the spurious failures for now.
Tweak the silent logic as requested, squeeze in a few more tests. The spurious w864 crash doesn't seem to be related to the patches, it happens there from time to time when the driver tests aren't executed and is probably caused by some invalid cleanup. FWIW, when I force start_driver code to fail on Wine in the same way it's failing on this machine, I also get a winedevice crash after the test has exited, on a call to PsGetCurrentProcessId() in winetest_cleanup. I have no idea if it's the same kind of thing, but it looks fishy.dlls/ntoskrnl.exe/tests/driver_hid.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/dlls/ntoskrnl.exe/tests/driver_hid.c b/dlls/ntoskrnl.exe/tests/driver_hid.c index 44ec1b09526..0f626e6866c 100644 --- a/dlls/ntoskrnl.exe/tests/driver_hid.c +++ b/dlls/ntoskrnl.exe/tests/driver_hid.c @@ -103,6 +103,7 @@ static const unsigned char report_descriptor[] =
static NTSTATUS WINAPI driver_internal_ioctl(DEVICE_OBJECT *device, IRP *irp) {
- static BOOL test_failed; IO_STACK_LOCATION *stack = IoGetCurrentIrpStackLocation(irp); const ULONG in_size = stack->Parameters.DeviceIoControl.InputBufferLength; const ULONG out_size = stack->Parameters.DeviceIoControl.OutputBufferLength;
@@ -175,11 +176,15 @@ static NTSTATUS WINAPI driver_internal_ioctl(DEVICE_OBJECT *device, IRP *irp) }
case IOCTL_HID_READ_REPORT:
{ULONG expected_size = 2; ok(!in_size, "got input size %u\n", in_size);
todo_wine ok(out_size == 2, "got output size %u\n", out_size);
if (!test_failed) todo_wine ok(out_size == expected_size, "got output size %u\n", out_size);if (out_size != expected_size) test_failed = TRUE; ret = STATUS_NOT_IMPLEMENTED; break;} case IOCTL_HID_GET_STRING: ok(!in_size, "got input size %u\n", in_size);
Hi!
Should I do something different for this series? I don't think the failures here are related to the additional tests.
Would it be better maybe to share the hid macros with PARENTSRC or move them to some public wine include?
Then it's not very convenient that the tests have to live in ntoskrnl.exe, and hid/hidclass.sys changes won't trigger any test run unless they touch some todo_wine.
The only other way I could think of to test HidP functions separately would be to dump PHIDP_PREPARSED_DATA blobs somehow and add them to hid/hidclass.sys tests, and it doesn't seem very robust.
Cheers,