On Wed, Jul 27, 2022 at 4:53 PM Konstantin Kostiuk <kkost...@redhat.com> wrote: > > > > > > On Wed, Jul 27, 2022 at 10:47 AM Bin Meng <bmeng...@gmail.com> wrote: >> >> From: Bin Meng <bin.m...@windriver.com> >> >> Support for the unix socket has existed both in BSD and Linux for the >> longest time, but not on Windows. Since Windows 10 build 17063 [1], >> the native support for the unix socket has came to Windows. Starting >> this build, two Win32 processes can use the AF_UNIX address family >> over Winsock API to communicate with each other. >> >> Introduce a new build time config option CONFIG_AF_UNIX when the build >> host has such a capability, and a run-time check afunix_available() for >> Windows host in the QEMU sockets util codes. >> >> [1] https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ >> >> Signed-off-by: Xuzhou Cheng <xuzhou.ch...@windriver.com> >> Signed-off-by: Bin Meng <bin.m...@windriver.com> >> --- >> >> meson.build | 6 ++++++ >> util/qemu-sockets.c | 48 ++++++++++++++++++++++++++++++++++++++------- >> 2 files changed, 47 insertions(+), 7 deletions(-) >> >> diff --git a/meson.build b/meson.build >> index 75aaca8462..73e5de5957 100644 >> --- a/meson.build >> +++ b/meson.build >> @@ -2327,6 +2327,12 @@ have_afalg = get_option('crypto_afalg') \ >> '''), error_message: 'AF_ALG requested but could not be >> detected').allowed() >> config_host_data.set('CONFIG_AF_ALG', have_afalg) >> >> +if targetos != 'windows' >> + config_host_data.set('CONFIG_AF_UNIX', true) >> +else >> + config_host_data.set('CONFIG_AF_UNIX', cc.has_header('afunix.h')) >> +endif >> + >> config_host_data.set('CONFIG_AF_VSOCK', cc.has_header_symbol( >> 'linux/vm_sockets.h', 'AF_VSOCK', >> prefix: '#include <sys/socket.h>', >> diff --git a/util/qemu-sockets.c b/util/qemu-sockets.c >> index 0e2298278f..d85f3ea3ee 100644 >> --- a/util/qemu-sockets.c >> +++ b/util/qemu-sockets.c >> @@ -17,6 +17,15 @@ >> */ >> #include "qemu/osdep.h" >> >> +#if defined(CONFIG_WIN32) && defined(CONFIG_AF_UNIX) >> +# include <afunix.h> >> +/* >> + * AF_UNIX support is available since Windows 10 build 17063 >> + * See https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ >> + */ >> +# define WIN_BUILD_AF_UNIX 17063 >> +#endif /* CONFIG_WIN32 && CONFIG_AF_UNIX */ >> + >> #ifdef CONFIG_AF_VSOCK >> #include <linux/vm_sockets.h> >> #endif /* CONFIG_AF_VSOCK */ >> @@ -880,7 +889,7 @@ static int vsock_parse(VsockSocketAddress *addr, const >> char *str, >> } >> #endif /* CONFIG_AF_VSOCK */ >> >> -#ifndef _WIN32 >> +#ifdef CONFIG_AF_UNIX >> >> static bool saddr_is_abstract(UnixSocketAddress *saddr) >> { >> @@ -900,6 +909,17 @@ static bool saddr_is_tight(UnixSocketAddress *saddr) >> #endif >> } >> >> +#ifdef CONFIG_WIN32 >> +static bool afunix_available(void) >> +{ >> + OSVERSIONINFOEXW os_version = { 0 }; >> + >> + os_get_win_version(&os_version); >> + >> + return os_version.dwBuildNumber >= WIN_BUILD_AF_UNIX; > > > I think this is a bad variant to check feature support by checking > Windows build. From my point, you should try to create an AF_UNIX > socket and if it fails then fall back to the old behavior. >
The caller intends to create an AF_UNIX socket, and if Windows does not have the capability, it fails, and we return -1 to the caller. I am not sure what old behavior we should fall back to. Regards, Bin
