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(a)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(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev