Re: [PATCH] qemu: event: Fix retrieval of the "service" field from graphics events

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 29, 2015 at 14:22:47 +0100, Daniel Berrange wrote:
> On Mon, Jun 29, 2015 at 03:17:50PM +0200, Peter Krempa wrote:
> > On Mon, Jun 29, 2015 at 13:47:50 +0100, Daniel Berrange wrote:
> > > On Mon, Jun 29, 2015 at 02:42:50PM +0200, Peter Krempa wrote:
> > > > qemu's event has following format:
> > > > 
> > > > {
> > > >     "timestamp": {
> > > >         "seconds": 1435580974,
> > > >         "microseconds": 82226
> > > >     },
> > > >     "event": "SPICE_INITIALIZED",
> > > >     "data": {
> > > >         "server": {
> > > >             "auth": "none",
> > > >             "port": "5900",
> > > >             "family": "ipv4",
> > > >             "host": "127.0.0.1"
> > > >         },
> > > >         "client": {
> > > >             "port": "53224",
> > > >             "family": "ipv4",
> > > >             "channel-type": 3,
> > > >             "connection-id": 1113096064,
> > > >             "host": "127.0.0.1",
> > > >             "channel-id": 0,
> > > >             "tls": false
> > > >         }
> > > >     }
> > > > }
> > > > 
> > > > Our code tried to extract the "service" field but qemu reports it as
> > > > "port".
> > > 
> > > Hmm, that's somewhat odd - did you check back historical versions of
> > > QEMU where this event was first introduced to see if it has always
> > > had this name ? It smells like the kind of thing that could have been
> > > a regression at some point
> > 
> > Actually the regression would be on the VNC side, since VNC uses
> > "service" and the function that I've modified handles both. I failed to
> > notice that fact at first.
> > 
> > I'll post a V2 with dual handling.
> 
> Hmm, are you saying QEMU uses a different field name when it has
> VNC vs SPICE ? If so that's a bug in QEMU that needs adressing (though
> of course we'd have to workaround it in libvirt too now).

Well, qemu uses different fields but they also use them in different
events (VNC_CONNECTED vs SPICE_CONNECTED) with different return
structures since spice provides a lot more data.

The issue is that libvirt tries to use the same handler for parsing the
data. I'm now conflicted whether to duplicate it or do a dual handler
for both. If we will ever want to parse more data from that we will need
a new function for that.

Peter

Attachment: signature.asc
Description: Digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]