Kernel mode tests?

[Damjan Jovanovic]

Hi

We've already got ntoskrnl.exe, hal.dll, mountmgr.sys and usbd.sys,
with at least usbhub.sys hopefully coming soon, and I've been thinking
it's a good idea to have some regressions tests for these.

The problem, of course, is that on Windows these all run in kernel mode.

So what would be a good way to structure these regression tests?

We could cross-compile each test to a .sys file, install and load
that, call it from user-space to run the tests, then unload and
uninstall. This would work, but has the problem that a lot of
complexity is necessary to set up the tests (driver signing,
administrator access, UAC, etc.), and any bugs that would crash a
user-space application would now crash Windows instead (we all know
how easy that is :-).

Another possibility might be to use a custom program loader to load
the Windows .sys file being tested into user-space, the way we do now
on Wine, and test it like that. This seems to preclude us from testing
ntoskrnl.exe and hal.dll though.

Any thoughts/ideas/suggestions?

Thank you
Damjan Jovanovic

[Saulius Krasuckas]

* On Fri, 19 Mar 2010, Damjan Jovanovic wrote:
> We've already got ntoskrnl.exe, hal.dll, mountmgr.sys and usbd.sys,
> The problem, of course, is that on Windows these all run in kernel mode.
>
> So what would be a good way to structure these regression tests?
>
> We could cross-compile each test to a .sys file,

Is it possible already using MinGW?
> install and load that, call it from user-space to run the tests, then 
> unload and uninstall.

Couldn't each test stay primarily as .exe with an accompanied .sys file?  
This would cover Kernel-User inter mode communication as well.
> This would work, but has the problem that a lot of
> complexity is necessary to set up the tests (driver signing,
> administrator access, UAC, etc.),

Some of WinAPI tests also requires Administrator access and UAC, AFAIK.
> and any bugs that would crash a user-space application would now crash 
> Windows instead (we all know how easy that is :-).

For me it isn't a problem, because a Win-box under the risk isn't required 
to do somehing else.

Besides, test drivers could probably use exception handling to prevent 
some crashes.  Ah, SEH is only particularly used in usual Wine's test 
executables, so this statement is of no use, probably.
> Another possibility might be to use a custom program loader to load the 
> Windows .sys file being tested into user-space, the way we do now on 
> Wine, and test it like that. This seems to preclude us from testing 
> ntoskrnl.exe and hal.dll though.

Plus it sounds like porting Wine core into Win32 and writing additional 
code to test the portage :(

Thus I vote for the first way.

S.

[Roderick Colenbrander]

On Fri, Mar 19, 2010 at 8:40 AM, Damjan Jovanovic  wrote:
> Hi
>
> We've already got ntoskrnl.exe, hal.dll, mountmgr.sys and usbd.sys,
> with at least usbhub.sys hopefully coming soon, and I've been thinking
> it's a good idea to have some regressions tests for these.
>
> The problem, of course, is that on Windows these all run in kernel mode.
>
> So what would be a good way to structure these regression tests?
>
> We could cross-compile each test to a .sys file, install and load
> that, call it from user-space to run the tests, then unload and
> uninstall. This would work, but has the problem that a lot of
> complexity is necessary to set up the tests (driver signing,
> administrator access, UAC, etc.), and any bugs that would crash a
> user-space application would now crash Windows instead (we all know
> how easy that is :-).
>
> Another possibility might be to use a custom program loader to load
> the Windows .sys file being tested into user-space, the way we do now
> on Wine, and test it like that. This seems to preclude us from testing
> ntoskrnl.exe and hal.dll though.
>
> Any thoughts/ideas/suggestions?
>
> Thank you
> Damjan Jovanovic

These test sound very specialized and I'm not sure if they can be run
by much people. I'm not sure if you should have to make it that
complex, to me it sounds like a perfect thing for the the vmware based
winetestbot service.

Roderick