qemu/io/Makefile.objs

io-obj-y = channel.o
io-obj-y += channel-buffer.o
io-obj-y += channel-command.o
io-obj-y += channel-file.o
io-obj-y += channel-socket.o
io-obj-y += channel-tls.o
io-obj-y += channel-watch.o
io-obj-y += channel-websock.o
io-obj-y += channel-util.o
io-obj-y += dns-resolver.o
io-obj-y += net-listener.o
io-obj-y += task.o
io: add abstract QIOChannel classes Start the new generic I/O channel framework by defining a QIOChannel abstract base class. This is designed to feel similar to GLib's GIOChannel, but with the addition of support for using iovecs, qemu error reporting, file descriptor passing, coroutine integration and use of the QOM framework for easier sub-classing. The intention is that anywhere in QEMU that almost anywhere that deals with sockets will use this new I/O infrastructure, so that it becomes trivial to then layer in support for TLS encryption. This will at least include the VNC server, char device backend and migration code. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2015-02-27 16:19:33 +00:00			`io-obj-y = channel.o`
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> 2015-09-15 17:27:33 +01:00			`io-obj-y += channel-buffer.o`
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> 2015-08-27 16:25:30 +01:00			`io-obj-y += channel-command.o`
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> 2015-02-27 18:25:25 +00:00			`io-obj-y += channel-file.o`
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> 2015-02-27 16:19:33 +00:00			`io-obj-y += channel-socket.o`
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> 2015-03-02 18:13:13 +00:00			`io-obj-y += channel-tls.o`
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> 2015-03-03 12:59:16 +00:00			`io-obj-y += channel-watch.o`
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> 2015-03-04 15:57:41 +00:00			`io-obj-y += channel-websock.o`
io: introduce helper for creating channels from file descriptors Depending on what object a file descriptor refers to a different type of IO channel will be needed - either a QIOChannelFile or a QIOChannelSocket. Introduce a qio_channel_new_fd() method which will return the appropriate channel implementation. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2016-02-03 14:00:28 +00:00			`io-obj-y += channel-util.o`
io: introduce a DNS resolver API Currently DNS resolution is done automatically as part of the creation of a QIOChannelSocket object instance. This works ok for network clients where you just end up a single network socket, but for servers, the results of DNS resolution may require creation of multiple sockets. Introducing a DNS resolver API allows DNS resolution to be separated from the socket object creation. This will make it practical to create multiple QIOChannelSocket instances for servers. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2016-07-19 12:54:47 +01:00			`io-obj-y += dns-resolver.o`
io: introduce a network socket listener API The existing QIOChannelSocket class provides the ability to listen on a single socket at a time. This patch introduces a QIONetListener class that provides a higher level API concept around listening for network services, allowing for listening on multiple sockets. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2016-07-19 13:37:51 +01:00			`io-obj-y += net-listener.o`
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> 2015-03-18 17:25:45 +00:00			`io-obj-y += task.o`