On Thu, Nov 07, 2024 at 11:17:30AM -0500, Peter Xu wrote: > On Thu, Nov 07, 2024 at 12:33:17PM +0000, Daniel P. Berrangé wrote: > I'll comment on a few examples above, which I think some of them, even if > handshake is ready, may still need mgmt layers to involve.. > > Multifd and postcopy are the two major features, and they, IMHO, all better > need user involvements.. > > Multifd needs it because it relies on the channel being able to provide >1 > channels. It means "| nc XXX > file" can stop working if we turn it on by > default silently.
NB, my point was referring to a hypothetical alternative history, where we had the handshake at the QEMU level from day 1. That would neccessarily imply a bi-directional channel, so the 'nc' use case would already have been out of scope. That said, QEMU could identify whether the channel it was told to use was bi-directional or not, and thus not try to do multifd over a non-socket transport. So the general point still holds - if QEMU had this protocol negotiation phase built-in, there would be more flexiblity in introducing new features without layers above needing changes, for every single one, just a subset. 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 :|
