Hi,
I guess I don't have to introduce myself all that much anymore ;) Please see [1] if you disagree.
I plan to submit a GSoC project proposal concerning the kernel-mode test suite, and would like to discuss a few key points to better shape the project idea and its timeline. Because of the broadness of the subject, I'm posting here to reach as many ears (er... eyes) as possible, hoping for feedback from people working on several different areas of ROS.
My "state of mind" is currently the following regarding the project:
Basic key points (I hope everyone agrees; please tell me if I'm wrong :p) - follow Winetest "feeling" - syntax for writing tests should be almost identical; like current kmtests demonstrate - tests should be startable individually from a command line launcher and follow Winetest behavior in that regard, so that an integration with Testman is made easy - code should be CMake and MSVC/WDK compatible from the beginning
Ideas I deem useful (would appreciate any comments) - include buffer overrun checks, much like DPH (DPH can't be used for this though, can it?), using e.g. a guard/noaccess page behind each buffer. See [2] for a userland example; I'm working on a kernel-mode one - inspired by Winetest's broken(), one could make tests Windows-version specific. Something like [but better thought-out in syntax] ok(win2k3sp1(ret == 0) | win7x64sp1(ret == 1), ...) This would help compare different versions of Windows and much facilitate future kernel-target switching
Questions - as there are ... many... kernel-mode functions, it is unfeasible to write tests for all during the project. My idea would be to create some very thorough sample tests, then focus on the most critical functions. "If there's time", thinly covering a more broad area might also be very useful (as extending existing tests is probably deemed easier than creating new ones by people later on). I have no doubt there's enough to do, ;) but would be interested to hear if you agree with the general strategy and what you think those "critical" areas might be.
So what do you guys think? Excited for your input. Thanks. :)
Regards, Tom
[1] Hi! I'm Thomas, 23, from Germany, currently studying Computer Engineering in Berlin. I've been hanging out on IRC as ThFabba for some time now and submitted some hopefully-not-totally-useless patches ;) I'm interested in.... oh well, pretty much all parts of ROS. *g* Nice to meet you!
Hi Thomas,
Considering your recent influx of patches and IRC activity, I'm sure you don't really need a reply from me advising what you need to do to apply, etc. I therefore wish you luck in your application.
Ged.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Thomas Faber Sent: 27 March 2011 21:56 To: ReactOS Development Mailing List Subject: [ros-dev] GSoC: Kernel-Mode Test Suite
Hi,
I guess I don't have to introduce myself all that much anymore ;) Please see [1] if you disagree.
I plan to submit a GSoC project proposal concerning the kernel-mode test suite, and would like to discuss a few key points to better shape the project idea and its timeline. Because of the broadness of the subject, I'm posting here to reach as many ears (er... eyes) as possible, hoping for feedback from people working on several different areas of ROS.
My "state of mind" is currently the following regarding the project:
Basic key points (I hope everyone agrees; please tell me if I'm wrong :p) - follow Winetest "feeling" - syntax for writing tests should be almost identical; like current kmtests demonstrate - tests should be startable individually from a command line launcher and follow Winetest behavior in that regard, so that an integration with Testman is made easy - code should be CMake and MSVC/WDK compatible from the beginning
Ideas I deem useful (would appreciate any comments) - include buffer overrun checks, much like DPH (DPH can't be used for this though, can it?), using e.g. a guard/noaccess page behind each buffer. See [2] for a userland example; I'm working on a kernel-mode one - inspired by Winetest's broken(), one could make tests Windows-version specific. Something like [but better thought-out in syntax] ok(win2k3sp1(ret == 0) | win7x64sp1(ret == 1), ...) This would help compare different versions of Windows and much facilitate future kernel-target switching
Questions - as there are ... many... kernel-mode functions, it is unfeasible to write tests for all during the project. My idea would be to create some very thorough sample tests, then focus on the most critical functions. "If there's time", thinly covering a more broad area might also be very useful (as extending existing tests is probably deemed easier than creating new ones by people later on). I have no doubt there's enough to do, ;) but would be interested to hear if you agree with the general strategy and what you think those "critical" areas might be.
So what do you guys think? Excited for your input. Thanks. :)
Regards, Tom
[1] Hi! I'm Thomas, 23, from Germany, currently studying Computer Engineering in Berlin. I've been hanging out on IRC as ThFabba for some time now and submitted some hopefully-not-totally-useless patches ;) I'm interested in.... oh well, pretty much all parts of ROS. *g* Nice to meet you!
[2] http://www.reactos.org/paste/index.php/8697/
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
-
Ged Murphy -
Thomas Faber