summaryrefslogtreecommitdiffstats
path: root/hw/usb-ohci.c
diff options
context:
space:
mode:
authorMichael Roth2012-02-07 20:56:48 +0100
committerMichael Roth2012-03-12 21:09:23 +0100
commit3cf0bed8369267184e5dc5b58882811519d67437 (patch)
treea9c32d61d08ec7ab795b1b2cc4d74252087e1130 /hw/usb-ohci.c
parentqemu-ga: add guest-network-get-interfaces command (diff)
downloadqemu-3cf0bed8369267184e5dc5b58882811519d67437.tar.gz
qemu-3cf0bed8369267184e5dc5b58882811519d67437.tar.xz
qemu-3cf0bed8369267184e5dc5b58882811519d67437.zip
qemu-ga: add guest-sync-delimited
guest-sync leaves it as an exercise to the user as to how to reliably obtain the response to guest-sync if the client had previously read in a partial response (due qemu-ga previously being restarted mid-"sentence" due to reboot, forced restart, etc). qemu-ga handles this situation on its end by having a client precede their guest-sync request with a 0xFF byte (invalid UTF-8), which qemu-ga/QEMU JSON parsers will treat as a flush event. Thus we can reliably flush the qemu-ga parser state in preparation for receiving the guest-sync request. guest-sync-delimited provides the same functionality for a client: when a guest-sync-delimited is issued, qemu-ga will precede it's response with a 0xFF byte that the client can use as an indicator to flush its buffer/parser state in preparation for reliably receiving the guest-sync-delimited response. It is also useful as an optimization for clients, since, after issuing a guest-sync-delimited, clients can safely discard all stale data read from the channel until the 0xFF is found. More information available on the wiki: http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
Diffstat (limited to 'hw/usb-ohci.c')
0 files changed, 0 insertions, 0 deletions