Re: [PATCH 07/16] hw/9pfs: Implement Windows specific utilities functions for 9pfs

[Christian Schoenebeck]

On Wednesday, November 2, 2022 12:28:08 PM CET Shi, Guohuai wrote:
> 
[...]
> > >
> > > 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
> > 
> 
> It is OK to add this just for current solution.
> My concern is:
> mode_t is a 16-bit value which store permission value in lower 12-bit and 
> file type in higher 4-bit.
> Windows does not document the other value for file type defines:
> 
> // from MS SDK header file:
> 
> #define _S_IFMT   0xF000 // File type mask
> #define _S_IFDIR  0x4000 // Directory
> #define _S_IFCHR  0x2000 // Character special
> #define _S_IFIFO  0x1000 // Pipe
> #define _S_IFREG  0x8000 // Regular
> 
> If we add a new type, is it a risk that the un-document value may be used by 
> Windows internally and cause some compatible issue?
> Or if Windows use this some values in the future cause conflict?

We don't have a crystal ball, but there are ways to handle this responsibly:
At compile-time you could error out badly if there is anything we don't
expect, like all of a sudden some of the macros we explicitly define for
Windows are unexpectly there, and telling developers, hey somebody should look
at this.

And at runtime you could add an assert() if some these values are all of a
sudden filled. Because that's what we currently don't expect, as we are
occupying them.

Best regards,
Christian Schoenebeck