* Daniel P. Berrangé (berra...@redhat.com) wrote: > 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.
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 / dgilb...@redhat.com / Manchester, UK
