On Wednesday, November 2, 2022 4:07:35 AM CET Shi, Guohuai wrote: > > > -----Original Message----- > > From: Christian Schoenebeck <qemu_...@crudebyte.com> > > Sent: Wednesday, November 2, 2022 02:22 > > To: qemu-devel@nongnu.org > > Cc: Greg Kurz <gr...@kaod.org>; Meng, Bin <bin.m...@windriver.com>; Shi, > > Guohuai <guohuai....@windriver.com> > > Subject: Re: [PATCH 07/16] hw/9pfs: Implement Windows specific utilities > > functions for 9pfs > > > > [Please note: This e-mail is from an EXTERNAL e-mail address] > > > > On Tuesday, November 1, 2022 4:20:53 PM CET Shi, Guohuai wrote: > > > > > [...] > > > > > > Windows POSIX API and MinGW library do not provide the NO_FOLLOW > > > > > > flag, and do not allow opening a directory by POSIX open(). This > > > > > > causes all > > > > > > xxx_at() functions cannot work directly. However, we can provide > > > > > > Windows handle based functions to emulate xxx_at() functions (e.g.: > > > > > > openat_win32, utimensat_win32, etc.). > > > > > > > > > > > > Windows does not support extended attributes. 9pfs for Windows > > > > > > uses NTFS ADS (Alternate Data Streams) to emulate extended > > attributes. > > > > > > > > > > > > Windows does not provide POSIX compatible readlink(), and > > > > > > symbolic link feature in 9pfs will be disabled on Windows. > > > > > > > > > > Wouldn't it be more user friendly if the relevant error locations > > > > > would use something like error_report_once() and suggesting to > > > > > enable > > > > > mapped(-xattr) to make 9p symlinks on guest working if desired by the > > user? > > > > > > > > > > Probably this error case would need to wrapped into a dedicated > > > > > function, otherwise I guess error_report_once() would fire several > > > > > times by different callers. > > > > > > > > > > > > > Windows (MinGW) does not only support symlink, but also does not > > > > have symlink definitions. > > > > Windows does not support symlink flags S_IFLNK. > > > > > > > > So even I add symlink support by mapped-xattr, the MinGW library > > > > does not have symlink flags and get a build error. > > > > And this flags is defined by Windows header files. > > > > The impact of adding a new flags to an pre-defined structure (struct > > > > stat) is unknown. > > > > > > > > So I think it is not a good idea to do that. > > > > > > Because Windows does not support symlink, so error_report_once() and > > > report > > it to user will be OK. > > > But mapped-xattr could not work. > > > > Showing an error makes sense for "passthrough" security model, but not for > > the "mapped" one. > > > > Just to avoid misapprehensions: are you aware that there is already a > > system- > > agnostic implementation for symlinks if "mapped" is used? > > > > When mapped security model is enabled, then creating symlinks on guest will > > simply create a corresponding *regular* file on host and the content of that > > regular file on host is the pointing path as raw string. Additionally the > > symlink flag is added to "virtfs.mode" xattr to mark that regular file as a > > symlink, a virtual one that is. So this does not require any support for > > symlinks by either the underlying host file system, nor by host OS. > > > > Likewise interpreting and walking those virtual symlinks in "mapped" mode is > > also implemented in the local fs driver already. > > Yes, symlink can be supported by "mapped" mode. > I mean that MinGW does not provide symlink mode flags "S_IFLNK" and some > other related functions and defines. > You can check with "9p.c": S_ISLNK, S_ISSOCK and S_ISFIFO are not valid on > Windows (MinGW) host. > So even I enabled symlink supported by "mapped" mode on local-agent code, > "9p.c" can not be built. > > So I disabled symlink totally, because MinGW interface does not support it. > > To resolve this issue, MinGW should add the missing defines at first.
And what's wrong with something like the following? #ifdef CONFIG_WIN32 ... #ifndef S_ISLNK #define S_ISLNK(x) ... #endif ... #endif Best regards, Christian Schoenebeck