| Message ID | 20220509173618.467207-1-lvivier@redhat.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | qapi: net: add unix socket type support to netdev backend | expand |
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
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.
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
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
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).
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 :| > >
"-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