Re: [RFC PATCH v3 00/11] qapi: net: add unix socket type support to netdev backend

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Daniel P. Berrangé (berrange@redhat.com) wrote:
> On Tue, Jun 21, 2022 at 11:31:36AM +0100, Dr. David Alan Gilbert wrote:
> > * Laurent Vivier (lvivier@redhat.com) wrote:
> > > On 20/06/2022 20:24, Dr. David Alan Gilbert wrote:
> > > > * Laurent Vivier (lvivier@redhat.com) 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.
> > > > > 
> > > > > Two new netdev backends, "stream" and "dgram" are added, that are barely a copy of "socket"
> > > > > backend but they use the SocketAddress QAPI to provide socket parameters.
> > > > > And then they also implement unix sockets (TCP and UDP).
> > > > 
> > > > Had you considered a -netdev chardev?
> > > > 
> > > 
> > > I think by definition a "chardev" doesn't behave like a "netdev". Moreover
> > > "chardev" is already a frontend for several backends (socket, udp, ...),
> > > this would mean we use the frontend "chardev" as a backend of a "netdev".
> > > More and more layers...
> > 
> > Yeh definitely more layers; but perhaps avoiding some duplication.
> > 
> > > And in the case of "-netdev dgram", we can use unix socket and
> > > sendto()/recv() while something like "-chardev udp,id=char0 -netdev
> > > chardev,chardev=char0,id=net0" doesn't support unix (see
> > > qio_channel_socket_dgram_sync()/socket_dgram()) and uses a
> > > "connect()/sendmsg()/recv()" (that really changes the behaviour of the
> > > backend)
> > 
> > It was -chardev socket, path=/unix/socket/path    that I was thinking
> > of; -chardev socket supports both tcp and unix already.
> 
> IMHO we've over-used & abused chardevs in contexts where we really
> should not have done. The chardev API is passable when all you need
> is a persistent bidirectional channel, but is a really bad fit for
> backends wanting to be aware of the dynamic connection oriented
> semantics that sockets offer. The hoops we've had to jump through
> in places to deal with having chardevs open asynchronously or deal
> with automatic chardev re-connection is quite gross.
> 
> Chardev in the past was convenient to use, because we were not so
> great at doing CLI syntax modelling & implementation, so it was
> useful to re-use the chardev code for socket address handling on
> the CLI.  We also didn't historically have nice APIs for dealing
> with sockets - if you didn't use chardevs, you were stuck with
> the raw sockets APIs. With our aim for CLI to be modelled &
> implemented with QAPI these days, that benefit of re-using chardevs
> for CLI is largely eliminated.  With our QIOChannel APIs, the
> benefits of re-using chardevs from an impl POV is also largely
> eliminated.

OK, fair enough.

Dave

> 
> 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 :|
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK