On Mittwoch, 13. April 2022 05:30:57 CEST Shi, Guohuai wrote: > > We have 3 fs drivers: local, synth, proxy. I don't mind about proxy, it is > > in bad shape and we will probably deprecate it in near future anyway. > > But it would be good to have support for the synth driver, because we are > > using it for running test cases and fuzzing tests (QA). > > synth driver can not be built on Windows platform (or cross build on > Linux). So the test cases can not work on Windows.
Could you please be more specific what kind of challenge you see for making the synth driver working on Windows? The synth driver is just a simple mockup driver [1] that simulates in-RAM-only a filesystem with a bunch of hard coded dirs and files, solely for the purpose to run test cases. So the synth driver does not interact with any real filesystem on host at all. My expectation therefore would be that it just needs to tweak some header includes and maybe declaring missing POSIX data types, which you have done for the local driver already anyway. BTW support for macOS hosts has just been recently added for 9p, I know it is different as its a POSIX OS, but maybe you might still find the diff [2] helpful. [1] https://wiki.qemu.org/Documentation/9p#9p_Filesystem_Drivers [2] https://gitlab.com/qemu-project/qemu/-/commit/f45cc81911adc772 > > What are the limitations against security_model=mapped on Windows? Keep in > > mind that with security_model=none you are very limited in what you can > > do with 9p. > > MSYS library does not support extend attribute (e.g. getxattr), > And does not support POSIX permission APIs (e.g. chmod, chown). > Security model is useless on Windows host. That would be security_model=passthrough, yes, that's not possible with msys. The recommended way in practice though is using security_model=mapped [3] for all systems, which should be possible to achieve with msys as well ... [3] https://wiki.qemu.org/Documentation/9psetup#Starting_the_Guest_directly > It is possible that to "map" extend attribute to NTFS stream data. > However, if Windows host media is not NTFS (e.g. FAT) which does not support > stream data, then the "map" can not work. ... yes exactly, it would make sense to use ADS [4] instead of xattr on Windows. ADS are available with NTFS and ReFS and maybe also with exFAT nowadays (?), not sure about the latter though. But I think it is fair enough to assume Windows users to either use NTFS or ReFS. And if they don't, you can still call error_report_once() to make user aware that seucrity_model=mapped(-xattr) requires a fileystem on Windows that supports ADS. [4] https://en.wikipedia.org/wiki/NTFS#Alternate_data_stream_(ADS) Best regards, Christian Schoenebeck
