e155494c | 11-Jan-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: some fixes to handling of /dev/null when running commands
The /dev/null file handle was leaked in a couple of places. There is also the possibility that both readfd and writefd point to the same
io: some fixes to handling of /dev/null when running commands
The /dev/null file handle was leaked in a couple of places. There is also the possibility that both readfd and writefd point to the same /dev/null file handle, so care must be taken not to close the same file handle twice.
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
0c0a55b2 | 11-Jan-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: increment counter when killing off subcommand
When killing the subcommand, it is intended to first send SIGTERM, then SIGKILL and only report an error if it still doesn't die after SIGKILL. The
io: increment counter when killing off subcommand
When killing the subcommand, it is intended to first send SIGTERM, then SIGKILL and only report an error if it still doesn't die after SIGKILL. The 'step' counter was not being incremented though, so the code never got past the SIGTERM stage.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
7b3c618a | 21-Dec-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: fix stack allocation when sending of file descriptors
When sending file descriptors over a socket, we have to allocate a data buffer to hold the FDs in the scmsghdr. Unfortunately we allocated t
io: fix stack allocation when sending of file descriptors
When sending file descriptors over a socket, we have to allocate a data buffer to hold the FDs in the scmsghdr. Unfortunately we allocated the buffer on the stack inside an if () {} block, but called sendmsg() outside the block. So the stack bytes holding the FDs were liable to be overwritten with other data. By luck this was not a problem when sending 1 FD, but if sending 2 or more then it would fail.
The fix is to simply move the variables outside the nested 'if' block. To keep valgrind quiet we also zero-initialize the 'control' buffer.
Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
d98e4eb7 | 15-Sep-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: add QIOChannelBuffer class
Add a QIOChannel subclass that is capable of performing I/O to/from a memory buffer. This implementation does not attempt to support concurrent readers & writers. It i
io: add QIOChannelBuffer class
Add a QIOChannel subclass that is capable of performing I/O to/from a memory buffer. This implementation does not attempt to support concurrent readers & writers. It is designed for serialized access where by a single thread at a time may write data, seek and then read data back out.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
195e14d0 | 27-Aug-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: add QIOChannelCommand class
Add a QIOChannel subclass that is capable of performing I/O to/from a separate process, via a pair of pipes. The command can be used for unidirectional or bi-directio
io: add QIOChannelCommand class
Add a QIOChannel subclass that is capable of performing I/O to/from a separate process, via a pair of pipes. The command can be used for unidirectional or bi-directional I/O.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
2d1d0e70 | 04-Mar-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: add QIOChannelWebsock class
Add a QIOChannel subclass that can run the websocket protocol over the top of another QIOChannel instance. This initial implementation is only capable of acting as a
io: add QIOChannelWebsock class
Add a QIOChannel subclass that can run the websocket protocol over the top of another QIOChannel instance. This initial implementation is only capable of acting as a websockets server. There is no support for acting as a websockets client yet.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
ed8ee42c | 02-Mar-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: add QIOChannelTLS class
Add a QIOChannel subclass that can run the TLS protocol over the top of another QIOChannel instance. The object provides a simplified API to perform the handshake when st
io: add QIOChannelTLS class
Add a QIOChannel subclass that can run the TLS protocol over the top of another QIOChannel instance. The object provides a simplified API to perform the handshake when starting the TLS session. The layering of TLS over the underlying channel does not have to be setup immediately. It is possible to take an existing QIOChannel that has done some handshake and then swap in the QIOChannelTLS layer. This allows for use with protocols which start TLS right away, and those which start plain text and then negotiate TLS.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
d6e48869 | 27-Feb-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: add QIOChannelFile class
Add a QIOChannel subclass that is capable of operating on things that are files, such as plain files, pipes, character/block devices, but notably not sockets.
Signed-of
io: add QIOChannelFile class
Add a QIOChannel subclass that is capable of operating on things that are files, such as plain files, pipes, character/block devices, but notably not sockets.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
559607ea | 27-Feb-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: add QIOChannelSocket class
Implement a QIOChannel subclass that supports sockets I/O. The implementation is able to manage a single socket file descriptor, whether a TCP/UNIX listener, TCP/UNIX
io: add QIOChannelSocket class
Implement a QIOChannel subclass that supports sockets I/O. The implementation is able to manage a single socket file descriptor, whether a TCP/UNIX listener, TCP/UNIX connection, or a UDP datagram. It provides APIs which can listen and connect either asynchronously or synchronously. Since there is no asynchronous DNS lookup API available, it uses the QIOTask helper for spawning a background thread to ensure non-blocking operation.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
b02db2d9 | 18-Mar-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: add QIOTask class for async operations
A number of I/O operations need to be performed asynchronously to avoid blocking the main loop. The caller of such APIs need to provide a callback to be in
io: add QIOTask class for async operations
A number of I/O operations need to be performed asynchronously to avoid blocking the main loop. The caller of such APIs need to provide a callback to be invoked on completion/error and need access to the error, if any. The small QIOTask provides a simple framework for dealing with such probes. The API docs inline provide an outline of how this is to be used.
Some functions don't have the ability to run asynchronously (eg getaddrinfo always blocks), so to facilitate their use, the task class provides a mechanism to run a blocking function in a thread, while triggering the completion callback in the main event loop thread. This easily allows any synchronous function to be made asynchronous, albeit at the cost of spawning a thread.
In this series, the QIOTask class will be used for things like the TLS handshake, the websockets handshake and TCP connect() progress.
The concept of QIOTask is inspired by the GAsyncResult interface / GTask class in the GIO libraries. The min version requirements on glib don't allow those to be used from QEMU, so QIOTask provides a facsimilie which can be easily switched to GTask in the future if the min version is increased.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|
1c809fa0 | 03-Mar-2015 |
Daniel P. Berrange <berrange@redhat.com> |
io: add helper module for creating watches on FDs
A number of the channel implementations will require the ability to create watches on file descriptors / sockets. To avoid duplicating this code in
io: add helper module for creating watches on FDs
A number of the channel implementations will require the ability to create watches on file descriptors / sockets. To avoid duplicating this code in each channel, provide a helper API for dealing with file descriptor watches.
There are two watch implementations provided. The first is useful for bi-directional file descriptors such as sockets, regular files, character devices, etc. The second works with a pair of unidirectional file descriptors such as pipes.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
show more ...
|