Message ID | 20220727073542.811420-1-bmeng.cn@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Enable unix socket support on Windows | expand |
On Wed, Jul 27, 2022 at 03:35:37PM +0800, Bin Meng wrote: > 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/ > > > Bin Meng (5): > util/qemu-sockets: Replace the call to close a socket with > closesocket() > util/oslib-win32: Add a helper to get the Windows version > qga/commands-win32: Use os_get_win_version() > util/qemu-sockets: Enable unix socket support on Windows > chardev/char-socket: Update AF_UNIX for Windows > > meson.build | 6 +++++ > include/sysemu/os-win32.h | 2 ++ > chardev/char-socket.c | 8 +++++- > qga/commands-win32.c | 27 +------------------- > util/oslib-win32.c | 15 +++++++++++ > util/qemu-sockets.c | 52 ++++++++++++++++++++++++++++++++------- > 6 files changed, 74 insertions(+), 36 deletions(-) What about net/socket.c ? Also there are many tests using AF_UNIX and this doesn't appear to have enablede any of them. I'd at least exepct to see the sockets tests-io-channel-socket.c test enabled to prove this functionality is working. There are a few other AF_UNIX references in teh code, though many seems to be Linux specific. With regards, Daniel
On Wed, Jul 27, 2022 at 5:06 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Wed, Jul 27, 2022 at 03:35:37PM +0800, Bin Meng wrote: > > 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/ > > > > > > Bin Meng (5): > > util/qemu-sockets: Replace the call to close a socket with > > closesocket() > > util/oslib-win32: Add a helper to get the Windows version > > qga/commands-win32: Use os_get_win_version() > > util/qemu-sockets: Enable unix socket support on Windows > > chardev/char-socket: Update AF_UNIX for Windows > > > > meson.build | 6 +++++ > > include/sysemu/os-win32.h | 2 ++ > > chardev/char-socket.c | 8 +++++- > > qga/commands-win32.c | 27 +------------------- > > util/oslib-win32.c | 15 +++++++++++ > > util/qemu-sockets.c | 52 ++++++++++++++++++++++++++++++++------- > > 6 files changed, 74 insertions(+), 36 deletions(-) > > What about net/socket.c ? It looks net/socket.c does not need to adapt. > Also there are many tests using AF_UNIX and this doesn't appear to > have enablede any of them. I'd at least exepct to see the sockets > tests-io-channel-socket.c test enabled to prove this functionality > is working. > Enabling qtest to run on Windows is underway but that's a separate topic. The qtest itself is using unix socket so as long as we can run qtest on Windows, we should be fine. I feel this series is independent enough of being a standalone one. > There are a few other AF_UNIX references in teh code, though many > seems to be Linux specific. Regards, Bin
On Wed, Jul 27, 2022 at 06:15:50PM +0800, Bin Meng wrote: > On Wed, Jul 27, 2022 at 5:06 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > On Wed, Jul 27, 2022 at 03:35:37PM +0800, Bin Meng wrote: > > > 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/ > > > > > > > > > Bin Meng (5): > > > util/qemu-sockets: Replace the call to close a socket with > > > closesocket() > > > util/oslib-win32: Add a helper to get the Windows version > > > qga/commands-win32: Use os_get_win_version() > > > util/qemu-sockets: Enable unix socket support on Windows > > > chardev/char-socket: Update AF_UNIX for Windows > > > > > > meson.build | 6 +++++ > > > include/sysemu/os-win32.h | 2 ++ > > > chardev/char-socket.c | 8 +++++- > > > qga/commands-win32.c | 27 +------------------- > > > util/oslib-win32.c | 15 +++++++++++ > > > util/qemu-sockets.c | 52 ++++++++++++++++++++++++++++++++------- > > > 6 files changed, 74 insertions(+), 36 deletions(-) > > > > What about net/socket.c ? > > It looks net/socket.c does not need to adapt. > > > Also there are many tests using AF_UNIX and this doesn't appear to > > have enablede any of them. I'd at least exepct to see the sockets > > tests-io-channel-socket.c test enabled to prove this functionality > > is working. > > > > Enabling qtest to run on Windows is underway but that's a separate > topic. The qtest itself is using unix socket so as long as we can run > qtest on Windows, we should be fine. > I feel this series is independent enough of being a standalone one. That isn't qtest, that is basic unit tests. I would expect those to be able to work with this series With regards, Daniel
On Wed, Jul 27, 2022 at 6:24 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > On Wed, Jul 27, 2022 at 06:15:50PM +0800, Bin Meng wrote: > > On Wed, Jul 27, 2022 at 5:06 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > > > > > > On Wed, Jul 27, 2022 at 03:35:37PM +0800, Bin Meng wrote: > > > > 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/ > > > > > > > > > > > > Bin Meng (5): > > > > util/qemu-sockets: Replace the call to close a socket with > > > > closesocket() > > > > util/oslib-win32: Add a helper to get the Windows version > > > > qga/commands-win32: Use os_get_win_version() > > > > util/qemu-sockets: Enable unix socket support on Windows > > > > chardev/char-socket: Update AF_UNIX for Windows > > > > > > > > meson.build | 6 +++++ > > > > include/sysemu/os-win32.h | 2 ++ > > > > chardev/char-socket.c | 8 +++++- > > > > qga/commands-win32.c | 27 +------------------- > > > > util/oslib-win32.c | 15 +++++++++++ > > > > util/qemu-sockets.c | 52 ++++++++++++++++++++++++++++++++------- > > > > 6 files changed, 74 insertions(+), 36 deletions(-) > > > > > > What about net/socket.c ? > > > > It looks net/socket.c does not need to adapt. > > > > > Also there are many tests using AF_UNIX and this doesn't appear to > > > have enablede any of them. I'd at least exepct to see the sockets > > > tests-io-channel-socket.c test enabled to prove this functionality > > > is working. > > > > > > > Enabling qtest to run on Windows is underway but that's a separate > > topic. The qtest itself is using unix socket so as long as we can run > > qtest on Windows, we should be fine. > > I feel this series is independent enough of being a standalone one. > > That isn't qtest, that is basic unit tests. I would expect those to > be able to work with this series > Ah, I see. Agreed, will do in v2. Regards, Bin
Am 27.07.22 um 13:37 schrieb Bin Meng: > On Wed, Jul 27, 2022 at 6:24 PM Daniel P. Berrangé <berrange@redhat.com> wrote: >> That isn't qtest, that is basic unit tests. I would expect those to >> be able to work with this series > Ah, I see. Agreed, will do in v2. > > Regards, > Bin In v2 you might also call RtlGetVersion directly instead of getting the address (that is only needed if we want to support old Windows versions which don't provide that function). Regards, Stefan
On Wed, Jul 27, 2022 at 7:45 PM Stefan Weil <sw@weilnetz.de> wrote: > > Am 27.07.22 um 13:37 schrieb Bin Meng: > > > On Wed, Jul 27, 2022 at 6:24 PM Daniel P. Berrangé <berrange@redhat.com> wrote: > >> That isn't qtest, that is basic unit tests. I would expect those to > >> be able to work with this series > > Ah, I see. Agreed, will do in v2. > > > > Regards, > > Bin > > > In v2 you might also call RtlGetVersion directly instead of getting the > address (that is only needed if we want to support old Windows versions > which don't provide that function). I can't find a way to directly call RtlGetVersion. This API is exported by ntdll so we have to do the indirect call via GetProcAddress. Regards, Bin