"Daniel P. Berrange" <berra...@redhat.com> writes: > On Wed, Feb 04, 2015 at 01:43:12PM +0100, Paolo Bonzini wrote: >> >> >> On 04/02/2015 12:32, Daniel P. Berrange wrote: >> > So my idea would be that we define a QEMUChannel object and set of APIs to >> > standardize all interaction with sockets, pipes, RDMA, whatever $channel, >> > and then convert the QEMU features I've mentioned over to use that. I think >> > that would be simpler than trying to untangle QEMUFile code from migration >> > and then extend its features. >> >> Could it be GIOChannel simply? >> >> 1) Chardev is already mostly a wrapper around GIOChannel >> >> 2) NBD and VNC could be converted to GIOChannel with relative ease >> >> 3) migration is more complicated because (unlike everything else) it >> uses a separate thread and blocking sockets, but you could probably >> write a GIOChannel-based implementation of QEMUFile. > > It might be possible to base it on GIOChannel, but IIRC some of the > migration code was using iovecs for I/O and GIOChannel API doesn't > allow for that. So you'd have to sacrifice performance by issuing a > separate syscall for each iovec element which seems sucky to me. > If you think that's an acceptable limitation though, I could certainly > explore use of GIOChannel. > > More broadly speaking GIOChannel has fallen out of favour in the > glib ecosystem, with most apps/libraries more focused on use of > the GIO APIs instead, but IIUC QEMU avoids use of the GIO library > due to need to support older glib versions.
Remind me: what GLib version are we targeting, and why? [...]
