Home
last modified time | relevance | path

Searched hist:"125 b310e" (Results 1 – 3 of 3) sorted by relevance

/openbmc/qemu/qga/
H A Dchannel.h125b310e Thu Jan 19 00:18:20 CST 2012 Michael Roth <mdroth@linux.vnet.ibm.com> qemu-ga: move channel/transport functionality into wrapper class

This is mostly in preparation for the win32 port, which won't use
GIO channels for reasons that will be made clearer later. Here the
GAChannel class is just a loose wrapper around GIOChannel
calls/callbacks, but we also roll in the logic/configuration for
various channel types and managing unix socket connections, which makes
the abstraction much more complete and further aids in the win32 port
since isa-serial/unix-listen will not be supported initially.

There's also a bit of refactoring in the main logic to consolidate the
exit paths so we can do common cleanup for things like pid files, which
weren't always cleaned up previously.
H A Dguest-agent-core.h125b310e Thu Jan 19 00:18:20 CST 2012 Michael Roth <mdroth@linux.vnet.ibm.com> qemu-ga: move channel/transport functionality into wrapper class

This is mostly in preparation for the win32 port, which won't use
GIO channels for reasons that will be made clearer later. Here the
GAChannel class is just a loose wrapper around GIOChannel
calls/callbacks, but we also roll in the logic/configuration for
various channel types and managing unix socket connections, which makes
the abstraction much more complete and further aids in the win32 port
since isa-serial/unix-listen will not be supported initially.

There's also a bit of refactoring in the main logic to consolidate the
exit paths so we can do common cleanup for things like pid files, which
weren't always cleaned up previously.
H A Dchannel-posix.c125b310e Thu Jan 19 00:18:20 CST 2012 Michael Roth <mdroth@linux.vnet.ibm.com> qemu-ga: move channel/transport functionality into wrapper class

This is mostly in preparation for the win32 port, which won't use
GIO channels for reasons that will be made clearer later. Here the
GAChannel class is just a loose wrapper around GIOChannel
calls/callbacks, but we also roll in the logic/configuration for
various channel types and managing unix socket connections, which makes
the abstraction much more complete and further aids in the win32 port
since isa-serial/unix-listen will not be supported initially.

There's also a bit of refactoring in the main logic to consolidate the
exit paths so we can do common cleanup for things like pid files, which
weren't always cleaned up previously.