Searched hist:"125 b310e" (Results 1 – 3 of 3) sorted by relevance
/openbmc/qemu/qga/ |
H A D | channel.h | 125b310e 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 D | guest-agent-core.h | 125b310e 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 D | channel-posix.c | 125b310e 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.
|