> -----Original Message----- > From: Christian Schoenebeck <qemu_...@crudebyte.com> > Sent: 2022年4月14日 19:24 > To: qemu-devel@nongnu.org; Shi, Guohuai <guohuai....@windriver.com> > Cc: Bin Meng <bmeng...@gmail.com>; Greg Kurz <gr...@kaod.org> > Subject: Re: [RFC PATCH 0/4] 9pfs: Add 9pfs support for Windows host > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > 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. >
For 9p-synth: I had enabled 9p-synth.c and built it successfully on Windows platform. However, test cases code are not built on Windows host. So I think it is useless that enable synth on Windows host (no way to run it). > 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) > Windows does not support POSIX permission. So I think that only allow user to use security_model=none is reasonable on Windows host. There is a difficulty to support "mapped" or "mapped-file" on Windows host: There are many functions in 9p-code using APIs like "openat", "mkdirat", etc. MSYS does not support that (openat is not valid on Windows host). I remember that 9p replaced "open" by "openat" for a long time. To fully support "security_model=mapped", 9p for Windows need to replace "openat" by "open". This may impact too many functions. I would have a try to enable "mapped" by using ADS, but it looks like a big refactor for 9p-local.c Best Regards, Guohuai
