Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels

[Markus Armbruster <armbru@redhat.com>]

"Daniel P. Berrange" <berrange@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?

[...]