Tuesday, June 20, 2006, 5:39:26 AM, Frans Kool wrote:
Hi Vitaliy,
If I read the thread concerning ntoskrnl insertion into Wine correctly, the patch will have to be divided into several parts to be accepted by AJ.
That is not the main problem. It will have to be divided, but it would be few pieces.
For this, tests need probably be written to make sure each sub-patch is performing as it should. I haven't written C-code for a while, but there are a lot of tests available for me to have a crack at it.
I'm not so sure how much can you test here. Under "tests" here we mean conformance tests that could be compiled as an exe and ran on native platforms. To test ntoskrnl you one would need kernel driver to test against. But this is not something that we can compile ourselves. It requires DDK. Also the only part that could be tested is ioctls, not the driver loading/unloading.
As I see it, the following tests/patches are needed (in this order?)
- Tests for talking to ntoskrnl through wineserver (setting up channel, testing
messages both correct and incorrect and closing channel again) in order to test the new way of communication.
This part can be a stand alone test, not a part of the test suite. It would be helpful of course but I'm not sure if it could be committed.
- Tests to try the ioctl structures
I'm not sure what you mean here. There are lots of data types associated with predefined ioctls. But that's not what we need here.
- loading a device driver, talking to it, unloading it (including negatives
like unloading a non-loaded driver etc).
This we can not really test with integrated tests. We need a driver and admin privileges.
- Open issues like detecting if the driver is actually loaded instead of
waiting X ms....
That's more of the design question. There are several ways how this could be done. It could be as simple as adding one more internal ioctl.
The questions I have are: a) Is the breakdown correct, or are there more atomic parts (easier to test/get into wine). Do you already have a breakdown idea of the patch into smaller parts so I/we can focus on this?
I would brake it down to the following pieces: 1. ioctls to the wineserver "devices" (named-pipe, mail-slot, etc). This is an atomic change. 2. Implementing ntoskrnl.exe. So far we have it as a separate program. It could be turned into a dll. 3. Other part of the ioctls (wineserver <-> ntoskrnl). 4. Pieces required to load/unload/query driver and processing ioctls. 5. Other pieces required for safedisc support (privileged instruction emulation, and process startup sequence).
d) Can I somehow access the most recent version of the patch? I have several versions now, but they keep on changing/improving(!). It would be nice if you could publish it somewhere (nightly CVS tarball?), so more people can provide feedback on it too.
I could make a current diff of what I have. But I don't really have time to make a daily snapshots.
As you can see, I'm just trying to see if I can contribute on such a big project. Thanks for the feedback,
Thank you for offering support in this area. I really do appreciate it.
Vitaliy