1. Patchew
  2. QEMU
  3. View series

[RFC PATCH 0/6] qapi: net: add unix socket type support to netdev backend

Laurent Vivier posted 6 patches 3 years, 9 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20220509173618.467207-1-lvivier@redhat.com
Maintainers: "Dr. David Alan Gilbert" <dgilbert@redhat.com>, "Daniel P. Berrangé" <berrange@redhat.com>, Jason Wang <jasowang@redhat.com>, Eric Blake <eblake@redhat.com>, Markus Armbruster <armbru@redhat.com>
There is a newer version of this series
hmp-commands.hx        |    2 +-
include/qemu/sockets.h |    2 +
net/clients.h          |    3 +
net/hub.c              |    1 +
net/meson.build        |    1 +
net/net.c              |  123 +++--
net/socket-ng.c        | 1060 ++++++++++++++++++++++++++++++++++++++++
qapi/net.json          |   41 +-
8 files changed, 1200 insertions(+), 33 deletions(-)
create mode 100644 net/socket-ng.c
[RFC PATCH 0/6] qapi: net: add unix socket type support to netdev backend
Posted by Laurent Vivier 3 years, 9 months ago 
"-netdev socket" only supports inet sockets.

It's not a complex task to add support for unix sockets, but
the socket netdev parameters are not defined to manage well unix
socket parameters.

As discussed in:

  "socket.c added support for unix domain socket datagram transport"
  https://lore.kernel.org/qemu-devel/1C0E1BC5-904F-46B0-8044-68E43E67BE60@gmail.com/

This series adds support of unix socket type using SocketAddress QAPI structure.

A new netdev backend "socket-ng" is added, that is barely a copy of "socket"
backend but it uses the SocketAddress QAPI to provide socket parameters.
And then it also implement unix sockets (TCP and UDP).

Some examples of CLI syntax:

  for TCP:

  -netdev socket-ng,id=socket0,mode=server,addr.type=inet,addr.host=localhost,addr.port=1234
  -netdev socket-ng,id=socket0,mode=client,addr.type=inet,addr.host=localhost,addr.port=1234

  -netdev socket-ng,id=socket0,mode=dgram,\
          local.type=inet,local.host=localhost,local.port=1234,\
          remote.type=inet,remote.host=localhost,remote.port=1235

  for UNIX:

  -netdev socket-ng,id=socket0,mode=server,addr.type=unix,addr.path=/tmp/qemu0
  -netdev socket-ng,id=socket0,mode=client,addr.type=unix,addr.path=/tmp/qemu0

  -netdev socket-ng,id=socket0,mode=dgram,\
          local.type=unix,local.path=/tmp/qemu0,\
          remote.type=unix,remote.path=/tmp/qemu1

  for FD:

  -netdev socket-ng,id=socket0,mode=server,addr.type=fd,addr.str=4
  -netdev socket-ng,id=socket0,mode=client,addr.type=fd,addr.str=5

  -netdev socket-ng,id=socket0,mode=dgram,local.type=fd,addr.str=4

CC: Ralph Schmieder <ralph.schmieder@gmail.com>
CC: Stefano Brivio <sbrivio@redhat.com>
CC: Daniel P. Berrangé <berrange@redhat.com>
CC: Markus Armbruster <armbru@redhat.com>

Laurent Vivier (6):
  net: introduce convert_host_port()
  qapi: net: add socket-ng netdev
  net: socket-ng: add unix socket for server and client mode.
  net: socket-ng: make dgram_dst generic
  net: socket-ng: move mcast specific code from
    net_socket_fd_init_dgram()
  net: socket-ng: add unix socket for dgram mode

 hmp-commands.hx        |    2 +-
 include/qemu/sockets.h |    2 +
 net/clients.h          |    3 +
 net/hub.c              |    1 +
 net/meson.build        |    1 +
 net/net.c              |  123 +++--
 net/socket-ng.c        | 1060 ++++++++++++++++++++++++++++++++++++++++
 qapi/net.json          |   41 +-
 8 files changed, 1200 insertions(+), 33 deletions(-)
 create mode 100644 net/socket-ng.c

-- 
2.35.3
Re: [RFC PATCH 0/6] qapi: net: add unix socket type support to netdev backend
Posted by Daniel P. Berrangé 3 years, 9 months ago 
On Mon, May 09, 2022 at 07:36:12PM +0200, Laurent Vivier wrote:
> "-netdev socket" only supports inet sockets.
> 
> It's not a complex task to add support for unix sockets, but
> the socket netdev parameters are not defined to manage well unix
> socket parameters.
> 
> As discussed in:
> 
>   "socket.c added support for unix domain socket datagram transport"
>   https://lore.kernel.org/qemu-devel/1C0E1BC5-904F-46B0-8044-68E43E67BE60@gmail.com/
> 
> This series adds support of unix socket type using SocketAddress QAPI structure.
> 
> A new netdev backend "socket-ng" is added, that is barely a copy of "socket"
> backend but it uses the SocketAddress QAPI to provide socket parameters.
> And then it also implement unix sockets (TCP and UDP).

So pulling in the QAPI from patch 2

   { 'enum': 'NetdevSocketNGMode',
     'data':  [ 'dgram', 'server', 'client' ] }

   { 'struct': 'NetdevSocketNGOptions',
     'data': {
       'mode':    'NetdevSocketNGMode',
       '*addr':   'SocketAddress',
       '*remote': 'SocketAddress',
       '*local':  'SocketAddress' } }

> Some examples of CLI syntax:
> 
>   for TCP:
> 
>   -netdev socket-ng,id=socket0,mode=server,addr.type=inet,addr.host=localhost,addr.port=1234
>   -netdev socket-ng,id=socket0,mode=client,addr.type=inet,addr.host=localhost,addr.port=1234
> 
>   -netdev socket-ng,id=socket0,mode=dgram,\
>           local.type=inet,local.host=localhost,local.port=1234,\
>           remote.type=inet,remote.host=localhost,remote.port=1235
> 
>   for UNIX:
> 
>   -netdev socket-ng,id=socket0,mode=server,addr.type=unix,addr.path=/tmp/qemu0
>   -netdev socket-ng,id=socket0,mode=client,addr.type=unix,addr.path=/tmp/qemu0
> 
>   -netdev socket-ng,id=socket0,mode=dgram,\
>           local.type=unix,local.path=/tmp/qemu0,\
>           remote.type=unix,remote.path=/tmp/qemu1
> 
>   for FD:
> 
>   -netdev socket-ng,id=socket0,mode=server,addr.type=fd,addr.str=4
>   -netdev socket-ng,id=socket0,mode=client,addr.type=fd,addr.str=5
> 
>   -netdev socket-ng,id=socket0,mode=dgram,local.type=fd,addr.str=4

                                                          ^^^ local.str=4

I notice that in all these examples, mode=client/server always use
the 'addr' field, and mode=dgram always uses the 'local'/'remote'
fields. IOW, there is almost no commonality between the dgram scenario
and the stream scenario, which feels sub-optimal.

Two alternatives come to mind

 - mode=client could use 'remote' and mode=server could use 'local',
   removing the 'addr' field entirely

 - Have completely separate backends, ie '-netdev stream' for
   client/server TCP/UNIX sockets, and '-netdev dgram' for UDP
   sockets, removing 'mode' field.

I'd have a slight preference for the second, since I'm not thrilled
by the 'socket-ng' name :-) 

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [RFC PATCH 0/6] qapi: net: add unix socket type support to netdev backend
Posted by Laurent Vivier 3 years, 9 months ago 
On 10/05/2022 10:26, Daniel P. Berrangé wrote:
> On Mon, May 09, 2022 at 07:36:12PM +0200, Laurent Vivier wrote:
>> "-netdev socket" only supports inet sockets.
>>
>> It's not a complex task to add support for unix sockets, but
>> the socket netdev parameters are not defined to manage well unix
>> socket parameters.
>>
>> As discussed in:
>>
>>    "socket.c added support for unix domain socket datagram transport"
>>    https://lore.kernel.org/qemu-devel/1C0E1BC5-904F-46B0-8044-68E43E67BE60@gmail.com/
>>
>> This series adds support of unix socket type using SocketAddress QAPI structure.
>>
>> A new netdev backend "socket-ng" is added, that is barely a copy of "socket"
>> backend but it uses the SocketAddress QAPI to provide socket parameters.
>> And then it also implement unix sockets (TCP and UDP).
> 
> So pulling in the QAPI from patch 2
> 
>     { 'enum': 'NetdevSocketNGMode',
>       'data':  [ 'dgram', 'server', 'client' ] }
> 
>     { 'struct': 'NetdevSocketNGOptions',
>       'data': {
>         'mode':    'NetdevSocketNGMode',
>         '*addr':   'SocketAddress',
>         '*remote': 'SocketAddress',
>         '*local':  'SocketAddress' } }
> 
>> Some examples of CLI syntax:
>>
>>    for TCP:
>>
>>    -netdev socket-ng,id=socket0,mode=server,addr.type=inet,addr.host=localhost,addr.port=1234
>>    -netdev socket-ng,id=socket0,mode=client,addr.type=inet,addr.host=localhost,addr.port=1234
>>
>>    -netdev socket-ng,id=socket0,mode=dgram,\
>>            local.type=inet,local.host=localhost,local.port=1234,\
>>            remote.type=inet,remote.host=localhost,remote.port=1235
>>
>>    for UNIX:
>>
>>    -netdev socket-ng,id=socket0,mode=server,addr.type=unix,addr.path=/tmp/qemu0
>>    -netdev socket-ng,id=socket0,mode=client,addr.type=unix,addr.path=/tmp/qemu0
>>
>>    -netdev socket-ng,id=socket0,mode=dgram,\
>>            local.type=unix,local.path=/tmp/qemu0,\
>>            remote.type=unix,remote.path=/tmp/qemu1
>>
>>    for FD:
>>
>>    -netdev socket-ng,id=socket0,mode=server,addr.type=fd,addr.str=4
>>    -netdev socket-ng,id=socket0,mode=client,addr.type=fd,addr.str=5
>>
>>    -netdev socket-ng,id=socket0,mode=dgram,local.type=fd,addr.str=4
> 
>                                                            ^^^ local.str=4
> 
> I notice that in all these examples, mode=client/server always use
> the 'addr' field, and mode=dgram always uses the 'local'/'remote'
> fields. IOW, there is almost no commonality between the dgram scenario
> and the stream scenario, which feels sub-optimal.
> 
> Two alternatives come to mind
> 
>   - mode=client could use 'remote' and mode=server could use 'local',
>     removing the 'addr' field entirely
> 
>   - Have completely separate backends, ie '-netdev stream' for
>     client/server TCP/UNIX sockets, and '-netdev dgram' for UDP
>     sockets, removing 'mode' field.
> 
> I'd have a slight preference for the second, since I'm not thrilled
> by the 'socket-ng' name :-)

It seems reasonable, I'm going to update my series in this way:

    { 'struct': 'NetdevStreamOptions',
      'data': {
        'addr':   'SocketAddress' } }

    { 'struct': 'NetdevDgramOptions',
      'data': {
       '*local':   'SocketAddress',
       '*remote':   'SocketAddress' } }

Both parameters are optional because:
multicast needs 'remote' for the multicast address and optionally a local for source 
address or fd.
unicast needs both, except for fd where local provides fd and remote is needed only if 
local is not an fd.

    { 'union': 'Netdev',
      'base': { 'id': 'str', 'type': 'NetClientDriver' },
      'discriminator': 'type',
      'data': {
      ...
      'stream': 'NetdevStreamOptions',
      'dgram': 'NetdevDgramOptions' } }

Thanks,
Laurent
Re: [RFC PATCH 0/6] qapi: net: add unix socket type support to netdev backend
Posted by Stefano Brivio 3 years, 9 months ago 
On Tue, 10 May 2022 09:26:39 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Mon, May 09, 2022 at 07:36:12PM +0200, Laurent Vivier wrote:
> > "-netdev socket" only supports inet sockets.
> > 
> > It's not a complex task to add support for unix sockets, but
> > the socket netdev parameters are not defined to manage well unix
> > socket parameters.
> > 
> > As discussed in:
> > 
> >   "socket.c added support for unix domain socket datagram transport"
> >   https://lore.kernel.org/qemu-devel/1C0E1BC5-904F-46B0-8044-68E43E67BE60@gmail.com/
> > 
> > This series adds support of unix socket type using SocketAddress QAPI structure.
> > 
> > A new netdev backend "socket-ng" is added, that is barely a copy of "socket"
> > backend but it uses the SocketAddress QAPI to provide socket parameters.
> > And then it also implement unix sockets (TCP and UDP).  
> 
> So pulling in the QAPI from patch 2
> 
>    { 'enum': 'NetdevSocketNGMode',
>      'data':  [ 'dgram', 'server', 'client' ] }
> 
>    { 'struct': 'NetdevSocketNGOptions',
>      'data': {
>        'mode':    'NetdevSocketNGMode',
>        '*addr':   'SocketAddress',
>        '*remote': 'SocketAddress',
>        '*local':  'SocketAddress' } }
> 
> > Some examples of CLI syntax:
> > 
> >   for TCP:
> > 
> >   -netdev socket-ng,id=socket0,mode=server,addr.type=inet,addr.host=localhost,addr.port=1234
> >   -netdev socket-ng,id=socket0,mode=client,addr.type=inet,addr.host=localhost,addr.port=1234
> > 
> >   -netdev socket-ng,id=socket0,mode=dgram,\
> >           local.type=inet,local.host=localhost,local.port=1234,\
> >           remote.type=inet,remote.host=localhost,remote.port=1235
> > 
> >   for UNIX:
> > 
> >   -netdev socket-ng,id=socket0,mode=server,addr.type=unix,addr.path=/tmp/qemu0
> >   -netdev socket-ng,id=socket0,mode=client,addr.type=unix,addr.path=/tmp/qemu0
> > 
> >   -netdev socket-ng,id=socket0,mode=dgram,\
> >           local.type=unix,local.path=/tmp/qemu0,\
> >           remote.type=unix,remote.path=/tmp/qemu1
> > 
> >   for FD:
> > 
> >   -netdev socket-ng,id=socket0,mode=server,addr.type=fd,addr.str=4
> >   -netdev socket-ng,id=socket0,mode=client,addr.type=fd,addr.str=5
> > 
> >   -netdev socket-ng,id=socket0,mode=dgram,local.type=fd,addr.str=4  
> 
>                                                           ^^^ local.str=4
> 
> I notice that in all these examples, mode=client/server always use
> the 'addr' field, and mode=dgram always uses the 'local'/'remote'
> fields. IOW, there is almost no commonality between the dgram scenario
> and the stream scenario, which feels sub-optimal.
> 
> Two alternatives come to mind
> 
>  - mode=client could use 'remote' and mode=server could use 'local',
>    removing the 'addr' field entirely

To me, "mode is client, address is x" sounds more intuitive than "mode
is client, remote is x". I mean, of course it's the remote address --
that's a bit redundant.

>  - Have completely separate backends, ie '-netdev stream' for
>    client/server TCP/UNIX sockets, and '-netdev dgram' for UDP
>    sockets, removing 'mode' field.

...this won't work, though, because UNIX domain sockets can be
stream-oriented or datagram-oriented.

-- 
Stefano
Re: [RFC PATCH 0/6] qapi: net: add unix socket type support to netdev backend
Posted by Daniel P. Berrangé 3 years, 9 months ago 
On Tue, May 10, 2022 at 10:59:08AM +0200, Stefano Brivio wrote:
> On Tue, 10 May 2022 09:26:39 +0100
> Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> > On Mon, May 09, 2022 at 07:36:12PM +0200, Laurent Vivier wrote:
> > > "-netdev socket" only supports inet sockets.
> > > 
> > > It's not a complex task to add support for unix sockets, but
> > > the socket netdev parameters are not defined to manage well unix
> > > socket parameters.
> > > 
> > > As discussed in:
> > > 
> > >   "socket.c added support for unix domain socket datagram transport"
> > >   https://lore.kernel.org/qemu-devel/1C0E1BC5-904F-46B0-8044-68E43E67BE60@gmail.com/
> > > 
> > > This series adds support of unix socket type using SocketAddress QAPI structure.
> > > 
> > > A new netdev backend "socket-ng" is added, that is barely a copy of "socket"
> > > backend but it uses the SocketAddress QAPI to provide socket parameters.
> > > And then it also implement unix sockets (TCP and UDP).  
> > 
> > So pulling in the QAPI from patch 2
> > 
> >    { 'enum': 'NetdevSocketNGMode',
> >      'data':  [ 'dgram', 'server', 'client' ] }
> > 
> >    { 'struct': 'NetdevSocketNGOptions',
> >      'data': {
> >        'mode':    'NetdevSocketNGMode',
> >        '*addr':   'SocketAddress',
> >        '*remote': 'SocketAddress',
> >        '*local':  'SocketAddress' } }
> > 
> > > Some examples of CLI syntax:
> > > 
> > >   for TCP:
> > > 
> > >   -netdev socket-ng,id=socket0,mode=server,addr.type=inet,addr.host=localhost,addr.port=1234
> > >   -netdev socket-ng,id=socket0,mode=client,addr.type=inet,addr.host=localhost,addr.port=1234
> > > 
> > >   -netdev socket-ng,id=socket0,mode=dgram,\
> > >           local.type=inet,local.host=localhost,local.port=1234,\
> > >           remote.type=inet,remote.host=localhost,remote.port=1235
> > > 
> > >   for UNIX:
> > > 
> > >   -netdev socket-ng,id=socket0,mode=server,addr.type=unix,addr.path=/tmp/qemu0
> > >   -netdev socket-ng,id=socket0,mode=client,addr.type=unix,addr.path=/tmp/qemu0
> > > 
> > >   -netdev socket-ng,id=socket0,mode=dgram,\
> > >           local.type=unix,local.path=/tmp/qemu0,\
> > >           remote.type=unix,remote.path=/tmp/qemu1
> > > 
> > >   for FD:
> > > 
> > >   -netdev socket-ng,id=socket0,mode=server,addr.type=fd,addr.str=4
> > >   -netdev socket-ng,id=socket0,mode=client,addr.type=fd,addr.str=5
> > > 
> > >   -netdev socket-ng,id=socket0,mode=dgram,local.type=fd,addr.str=4  
> > 
> >                                                           ^^^ local.str=4
> > 
> > I notice that in all these examples, mode=client/server always use
> > the 'addr' field, and mode=dgram always uses the 'local'/'remote'
> > fields. IOW, there is almost no commonality between the dgram scenario
> > and the stream scenario, which feels sub-optimal.
> > 
> > Two alternatives come to mind
> > 
> >  - mode=client could use 'remote' and mode=server could use 'local',
> >    removing the 'addr' field entirely
> 
> To me, "mode is client, address is x" sounds more intuitive than "mode
> is client, remote is x". I mean, of course it's the remote address --
> that's a bit redundant.
> 
> >  - Have completely separate backends, ie '-netdev stream' for
> >    client/server TCP/UNIX sockets, and '-netdev dgram' for UDP
> >    sockets, removing 'mode' field.
> 
> ...this won't work, though, because UNIX domain sockets can be
> stream-oriented or datagram-oriented.

Sure it can work, both the 'stream' and 'dgram' backends would
allow the full range of addr types as they're independant config
dimensions


    -netdev stream,server=no,addr.type=inet,addr.host=localhost,addr.port=1234
    -netdev stream,server=no,addr.type=unix,addr.path=/some/stream/sock


    -netdev dgram,id=ndev0,\
            local.type=inet,local.host=localhost,local.port=1234,\
            remote.type=inet,remote.host=localhost,remote.port=1235
    -netdev dgram,id=ndev0,\
            local.type=unix,local.path=/some/dgram/sock0,
            remote.type=unix,remote.path=/some/dgram/sock1


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
Re: [RFC PATCH 0/6] qapi: net: add unix socket type support to netdev backend
Posted by Ralph Schmieder 3 years, 9 months ago 
This looks very promising to me as it provides the flexibility needed for
all the permutations.  Thanks for looking into it!

On Tue, May 10, 2022 at 11:22 AM Daniel P. Berrangé <berrange@redhat.com>
wrote:

> On Tue, May 10, 2022 at 10:59:08AM +0200, Stefano Brivio wrote:
> > On Tue, 10 May 2022 09:26:39 +0100
> > Daniel P. Berrangé <berrange@redhat.com> wrote:
> >
> > > On Mon, May 09, 2022 at 07:36:12PM +0200, Laurent Vivier wrote:
> > > > "-netdev socket" only supports inet sockets.
> > > >
> > > > It's not a complex task to add support for unix sockets, but
> > > > the socket netdev parameters are not defined to manage well unix
> > > > socket parameters.
> > > >
> > > > As discussed in:
> > > >
> > > >   "socket.c added support for unix domain socket datagram transport"
> > > >
> https://lore.kernel.org/qemu-devel/1C0E1BC5-904F-46B0-8044-68E43E67BE60@gmail.com/
> > > >
> > > > This series adds support of unix socket type using SocketAddress
> QAPI structure.
> > > >
> > > > A new netdev backend "socket-ng" is added, that is barely a copy of
> "socket"
> > > > backend but it uses the SocketAddress QAPI to provide socket
> parameters.
> > > > And then it also implement unix sockets (TCP and UDP).
> > >
> > > So pulling in the QAPI from patch 2
> > >
> > >    { 'enum': 'NetdevSocketNGMode',
> > >      'data':  [ 'dgram', 'server', 'client' ] }
> > >
> > >    { 'struct': 'NetdevSocketNGOptions',
> > >      'data': {
> > >        'mode':    'NetdevSocketNGMode',
> > >        '*addr':   'SocketAddress',
> > >        '*remote': 'SocketAddress',
> > >        '*local':  'SocketAddress' } }
> > >
> > > > Some examples of CLI syntax:
> > > >
> > > >   for TCP:
> > > >
> > > >   -netdev
> socket-ng,id=socket0,mode=server,addr.type=inet,addr.host=localhost,addr.port=1234
> > > >   -netdev
> socket-ng,id=socket0,mode=client,addr.type=inet,addr.host=localhost,addr.port=1234
> > > >
> > > >   -netdev socket-ng,id=socket0,mode=dgram,\
> > > >           local.type=inet,local.host=localhost,local.port=1234,\
> > > >           remote.type=inet,remote.host=localhost,remote.port=1235
> > > >
> > > >   for UNIX:
> > > >
> > > >   -netdev
> socket-ng,id=socket0,mode=server,addr.type=unix,addr.path=/tmp/qemu0
> > > >   -netdev
> socket-ng,id=socket0,mode=client,addr.type=unix,addr.path=/tmp/qemu0
> > > >
> > > >   -netdev socket-ng,id=socket0,mode=dgram,\
> > > >           local.type=unix,local.path=/tmp/qemu0,\
> > > >           remote.type=unix,remote.path=/tmp/qemu1
> > > >
> > > >   for FD:
> > > >
> > > >   -netdev socket-ng,id=socket0,mode=server,addr.type=fd,addr.str=4
> > > >   -netdev socket-ng,id=socket0,mode=client,addr.type=fd,addr.str=5
> > > >
> > > >   -netdev socket-ng,id=socket0,mode=dgram,local.type=fd,addr.str=4
> > >
> > >                                                           ^^^
> local.str=4
> > >
> > > I notice that in all these examples, mode=client/server always use
> > > the 'addr' field, and mode=dgram always uses the 'local'/'remote'
> > > fields. IOW, there is almost no commonality between the dgram scenario
> > > and the stream scenario, which feels sub-optimal.
> > >
> > > Two alternatives come to mind
> > >
> > >  - mode=client could use 'remote' and mode=server could use 'local',
> > >    removing the 'addr' field entirely
> >
> > To me, "mode is client, address is x" sounds more intuitive than "mode
> > is client, remote is x". I mean, of course it's the remote address --
> > that's a bit redundant.
> >
> > >  - Have completely separate backends, ie '-netdev stream' for
> > >    client/server TCP/UNIX sockets, and '-netdev dgram' for UDP
> > >    sockets, removing 'mode' field.
> >
> > ...this won't work, though, because UNIX domain sockets can be
> > stream-oriented or datagram-oriented.
>
> Sure it can work, both the 'stream' and 'dgram' backends would
> allow the full range of addr types as they're independant config
> dimensions
>
>
>     -netdev
> stream,server=no,addr.type=inet,addr.host=localhost,addr.port=1234
>     -netdev stream,server=no,addr.type=unix,addr.path=/some/stream/sock
>
>
>     -netdev dgram,id=ndev0,\
>             local.type=inet,local.host=localhost,local.port=1234,\
>             remote.type=inet,remote.host=localhost,remote.port=1235
>     -netdev dgram,id=ndev0,\
>             local.type=unix,local.path=/some/dgram/sock0,
>             remote.type=unix,remote.path=/some/dgram/sock1
>
>
> With regards,
> Daniel
> --
> |: https://berrange.com      -o-
> https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-
> https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-
> https://www.instagram.com/dberrange :|
>
>

-- 
Ralph Schmieder
Holtzstr. 2
76135 Karlsruhe
Germany
ralph.schmieder@gmail.com
Re: [RFC PATCH 0/6] qapi: net: add unix socket type support to netdev backend
Posted by Stefano Brivio 3 years, 9 months ago 
On Tue, 10 May 2022 10:22:48 +0100
Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Tue, May 10, 2022 at 10:59:08AM +0200, Stefano Brivio wrote:
> > On Tue, 10 May 2022 09:26:39 +0100
> > Daniel P. Berrangé <berrange@redhat.com> wrote:
> >   
> > > On Mon, May 09, 2022 at 07:36:12PM +0200, Laurent Vivier wrote:  
> > > > "-netdev socket" only supports inet sockets.
> > > > 
> > > > It's not a complex task to add support for unix sockets, but
> > > > the socket netdev parameters are not defined to manage well unix
> > > > socket parameters.
> > > > 
> > > > As discussed in:
> > > > 
> > > >   "socket.c added support for unix domain socket datagram transport"
> > > >   https://lore.kernel.org/qemu-devel/1C0E1BC5-904F-46B0-8044-68E43E67BE60@gmail.com/
> > > > 
> > > > This series adds support of unix socket type using SocketAddress QAPI structure.
> > > > 
> > > > A new netdev backend "socket-ng" is added, that is barely a copy of "socket"
> > > > backend but it uses the SocketAddress QAPI to provide socket parameters.
> > > > And then it also implement unix sockets (TCP and UDP).    
> > > 
> > > So pulling in the QAPI from patch 2
> > > 
> > >    { 'enum': 'NetdevSocketNGMode',
> > >      'data':  [ 'dgram', 'server', 'client' ] }
> > > 
> > >    { 'struct': 'NetdevSocketNGOptions',
> > >      'data': {
> > >        'mode':    'NetdevSocketNGMode',
> > >        '*addr':   'SocketAddress',
> > >        '*remote': 'SocketAddress',
> > >        '*local':  'SocketAddress' } }
> > >   
> > > > Some examples of CLI syntax:
> > > > 
> > > >   for TCP:
> > > > 
> > > >   -netdev socket-ng,id=socket0,mode=server,addr.type=inet,addr.host=localhost,addr.port=1234
> > > >   -netdev socket-ng,id=socket0,mode=client,addr.type=inet,addr.host=localhost,addr.port=1234
> > > > 
> > > >   -netdev socket-ng,id=socket0,mode=dgram,\
> > > >           local.type=inet,local.host=localhost,local.port=1234,\
> > > >           remote.type=inet,remote.host=localhost,remote.port=1235
> > > > 
> > > >   for UNIX:
> > > > 
> > > >   -netdev socket-ng,id=socket0,mode=server,addr.type=unix,addr.path=/tmp/qemu0
> > > >   -netdev socket-ng,id=socket0,mode=client,addr.type=unix,addr.path=/tmp/qemu0
> > > > 
> > > >   -netdev socket-ng,id=socket0,mode=dgram,\
> > > >           local.type=unix,local.path=/tmp/qemu0,\
> > > >           remote.type=unix,remote.path=/tmp/qemu1
> > > > 
> > > >   for FD:
> > > > 
> > > >   -netdev socket-ng,id=socket0,mode=server,addr.type=fd,addr.str=4
> > > >   -netdev socket-ng,id=socket0,mode=client,addr.type=fd,addr.str=5
> > > > 
> > > >   -netdev socket-ng,id=socket0,mode=dgram,local.type=fd,addr.str=4    
> > > 
> > >                                                           ^^^ local.str=4
> > > 
> > > I notice that in all these examples, mode=client/server always use
> > > the 'addr' field, and mode=dgram always uses the 'local'/'remote'
> > > fields. IOW, there is almost no commonality between the dgram scenario
> > > and the stream scenario, which feels sub-optimal.
> > > 
> > > Two alternatives come to mind
> > > 
> > >  - mode=client could use 'remote' and mode=server could use 'local',
> > >    removing the 'addr' field entirely  
> > 
> > To me, "mode is client, address is x" sounds more intuitive than "mode
> > is client, remote is x". I mean, of course it's the remote address --
> > that's a bit redundant.
> >   
> > >  - Have completely separate backends, ie '-netdev stream' for
> > >    client/server TCP/UNIX sockets, and '-netdev dgram' for UDP
> > >    sockets, removing 'mode' field.  

Well, this ^^^ is one thing ('-netdev stream' for UNIX sockets),

> > ...this won't work, though, because UNIX domain sockets can be
> > stream-oriented or datagram-oriented.  
> 
> Sure it can work, both the 'stream' and 'dgram' backends would
> allow the full range of addr types as they're independant config
> dimensions
> 
> 
>     -netdev stream,server=no,addr.type=inet,addr.host=localhost,addr.port=1234
>     -netdev stream,server=no,addr.type=unix,addr.path=/some/stream/sock
> 
> 
>     -netdev dgram,id=ndev0,\
>             local.type=inet,local.host=localhost,local.port=1234,\
>             remote.type=inet,remote.host=localhost,remote.port=1235
>     -netdev dgram,id=ndev0,\
>             local.type=unix,local.path=/some/dgram/sock0,
>             remote.type=unix,remote.path=/some/dgram/sock1

...and this ('-netdev dgram' for UNIX sockets) is another one. :)

Indeed they're independent though, so I also prefer this version (with
the details Laurent just provided).

-- 
Stefano

Patchew 2.1-devel-b67e4c2

© 2016 - 2026 Red Hat, Inc.