Re: [Qemu-devel] Make 9pfs buildable for Windows

[Michael Fritscher]

Hi,

> Sorry for the late reply... Since I have only limited bandwidth, I'll only
> be able to provide some limited feedback.
No problem!

>
> A global remark to start with: it is a usual practice to prefix each patch
> title with the component's name, as explained here:
>
> https://wiki.qemu.org/Contribute/SubmitAPatch#Write_a_meaningful_commit_message
>
> eg, patch titles in this series should start with something like with
> fsdev: or
> 9pfs: or oslib-win32:
Yes, I've seen that I forgot this a few minutes too late.


>> this is the patch series to make 9pfs buildable (not working!) on
>> Windows.
>> It is compiling and starts, but obvousily 9pfs is not working - in fact
>> it
>> spits out a initializing error.
>>
>
> What's the error message ?
Sadly I havn't a binary here - it was somthing like "couldn't initialize
the 9pfs". This came only if the cmdline tried to use 9pfs, so it was no
regression. The technical cause was that it tried to use a incompatible
path.

>
> Any updates ? Not sure people will spend time reviewing this series until
> something actually works.
>

The main thing was the question whether to make a sort of "hack" to
emulate the *at commands (which is the way used by the patch, the main
idea using /proc/<pid>/fd information) or make a 9pfs_local_windows
variant which uses the native ntdll api. Which is ... another style of
codeing, let me say it this way...

To get an idea I've attached the "main" code with my experiments to open
the directory. The main question is: Is this kind of code ok? Sadly it
seems the only way to access the ntdll's function, which in turn is the
only way to have *at aquivalents.

Yes, the code is a bit dirty (very WIP). Additionally, I seem to destroy
the stack, because after running this function qemu exists. Fixing this is
my next step.

Best regards,
Michael Fritscher

9pfs_windows_code.c
Description: Text document