mbox series

[0/5] Enable unix socket support on Windows

Message ID 20220727073542.811420-1-bmeng.cn@gmail.com (mailing list archive)
Headers show
Series Enable unix socket support on Windows | expand

Message

Bin Meng July 27, 2022, 7:35 a.m. UTC
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(-)

Comments

Daniel P. Berrangé July 27, 2022, 9:06 a.m. UTC | #1
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
Bin Meng July 27, 2022, 10:15 a.m. UTC | #2
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
Daniel P. Berrangé July 27, 2022, 10:24 a.m. UTC | #3
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
Bin Meng July 27, 2022, 11:37 a.m. UTC | #4
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
Stefan Weil July 27, 2022, 11:45 a.m. UTC | #5
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
Bin Meng July 27, 2022, 12:17 p.m. UTC | #6
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