qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 4/5] util/qemu-sockets: Enable unix socket support on Windows


From: Bin Meng
Subject: Re: [PATCH 4/5] util/qemu-sockets: Enable unix socket support on Windows
Date: Thu, 28 Jul 2022 21:41:21 +0800

On Thu, Jul 28, 2022 at 9:11 PM Marc-André Lureau
<marcandre.lureau@gmail.com> wrote:
>
> Hi
>
> On Wed, Jul 27, 2022 at 2:05 PM Bin Meng <bmeng.cn@gmail.com> wrote:
>>
>> On Wed, Jul 27, 2022 at 4:53 PM Konstantin Kostiuk <kkostiuk@redhat.com> 
>> wrote:
>> >
>> >
>> >
>> >
>> >
>> > On Wed, Jul 27, 2022 at 10:47 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>> >>
>> >> From: Bin Meng <bin.meng@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.cheng@windriver.com>
>> >> Signed-off-by: Bin Meng <bin.meng@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.
>>
>
> I agree with Konstantin, we shouldn't check the Windows version, but assume 
> the socket creation can work, and just report a regular error if not.
>
> (you can drop some of the preliminary patch then)
>

Sure, will do in v3.

Regards,
Bin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]