From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Greg Kurz <groug@kaod.org>, "Meng, Bin" <Bin.Meng@windriver.com>,
"Shi, Guohuai" <Guohuai.Shi@windriver.com>
Subject: Re: [PATCH 07/16] hw/9pfs: Implement Windows specific utilities functions for 9pfs
Date: Wed, 02 Nov 2022 12:05:52 +0100 [thread overview]
Message-ID: <4078234.fJnRZ6glpc@silver> (raw)
In-Reply-To: <MN2PR11MB417324B0200E8841884C5C2AEF399@MN2PR11MB4173.namprd11.prod.outlook.com>
On Wednesday, November 2, 2022 4:07:35 AM CET Shi, Guohuai wrote:
>
> > -----Original Message-----
> > From: Christian Schoenebeck <qemu_oss@crudebyte.com>
> > Sent: Wednesday, November 2, 2022 02:22
> > To: qemu-devel@nongnu.org
> > Cc: Greg Kurz <groug@kaod.org>; Meng, Bin <Bin.Meng@windriver.com>; Shi,
> > Guohuai <Guohuai.Shi@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
next prev parent reply other threads:[~2022-11-02 11:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-24 4:57 [PATCH 00/16] hw/9pfs: Add 9pfs support for Windows Bin Meng
2022-10-24 4:57 ` [PATCH 01/16] qemu/xattr.h: Exclude <sys/xattr.h> " Bin Meng
2022-10-24 4:57 ` [PATCH 02/16] hw/9pfs: Drop unnecessary *xattr wrapper API declarations Bin Meng
2022-10-24 4:57 ` [PATCH 03/16] hw/9pfs: Replace the direct call to xxxat() APIs with a wrapper Bin Meng
2022-10-24 4:57 ` [PATCH 04/16] hw/9pfs: Introduce an opaque type 9P_FILE_ID Bin Meng
2022-11-01 13:55 ` Christian Schoenebeck
2022-10-24 4:57 ` [PATCH 05/16] hw/9pfs: Update P9_FILE_ID to support Windows Bin Meng
2022-10-24 4:57 ` [PATCH 06/16] hw/9pfs: Add missing definitions for Windows Bin Meng
2022-10-24 4:57 ` [PATCH 07/16] hw/9pfs: Implement Windows specific utilities functions for 9pfs Bin Meng
2022-11-01 14:27 ` Christian Schoenebeck
2022-11-01 15:13 ` Shi, Guohuai
2022-11-01 15:20 ` Shi, Guohuai
2022-11-01 18:22 ` Christian Schoenebeck
2022-11-02 3:07 ` Shi, Guohuai
2022-11-02 11:05 ` Christian Schoenebeck [this message]
2022-11-02 11:28 ` Shi, Guohuai
2022-11-02 11:51 ` Christian Schoenebeck
2022-11-02 12:06 ` Christian Schoenebeck
2022-10-24 4:57 ` [PATCH 08/16] hw/9pfs: Handle current directory offset for Windows Bin Meng
2022-11-01 14:41 ` Christian Schoenebeck
2022-10-24 4:57 ` [PATCH 09/16] hw/9pfs: Disable unsupported flags and features " Bin Meng
2022-11-01 15:04 ` Christian Schoenebeck
2022-11-01 15:34 ` Shi, Guohuai
2022-11-01 18:59 ` Christian Schoenebeck
2022-11-02 3:44 ` Shi, Guohuai
2022-11-02 11:34 ` Christian Schoenebeck
2022-11-02 12:19 ` Shi, Guohuai
2022-10-24 4:57 ` [PATCH 10/16] hw/9pfs: Update the local fs driver to support Windows Bin Meng
2022-10-24 4:57 ` [PATCH 11/16] hw/9pfs: Add Linux error number definition Bin Meng
2022-11-01 15:21 ` Christian Schoenebeck
2022-10-24 4:57 ` [PATCH 12/16] hw/9pfs: Translate Windows errno to Linux value Bin Meng
2022-10-24 4:57 ` [PATCH 13/16] fsdev: Disable proxy fs driver on Windows Bin Meng
2022-10-24 4:57 ` [PATCH 14/16] hw/9pfs: Update synth fs driver for Windows Bin Meng
2022-10-24 4:57 ` [PATCH 15/16] tests/qtest: virtio-9p-test: Adapt the case for win32 Bin Meng
2022-10-25 15:55 ` Thomas Huth
2022-11-01 15:32 ` Christian Schoenebeck
2022-10-24 4:57 ` [PATCH 16/16] meson.build: Turn on virtfs for Windows Bin Meng
2022-10-27 16:19 ` [PATCH 00/16] hw/9pfs: Add 9pfs support " Bin Meng
2022-10-27 16:30 ` Christian Schoenebeck
2022-10-28 2:25 ` Bin Meng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4078234.fJnRZ6glpc@silver \
--to=qemu_oss@crudebyte.com \
--cc=Bin.Meng@windriver.com \
--cc=Guohuai.Shi@windriver.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).