On Tue, Jun 21, 2022 at 11:31:36AM +0100, Dr. David Alan Gilbert wrote: > * Laurent Vivier (lviv...@redhat.com) wrote: > > On 20/06/2022 20:24, Dr. David Alan Gilbert wrote: > > > * Laurent Vivier (lviv...@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-68e43e67b...@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. 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 :|
