#
ec5b6c9c |
| 06-Oct-2022 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
io/command: implement support for win32
The initial implementation was changing the pipe state created by GLib to PIPE_NOWAIT, but it turns out it doesn't work (read/write returns an error). Since r
io/command: implement support for win32
The initial implementation was changing the pipe state created by GLib to PIPE_NOWAIT, but it turns out it doesn't work (read/write returns an error). Since reading may return less than the requested amount, it seems to be non-blocking already. However, the IO operation may block until the FD is ready, I can't find good sources of information, to be safe we can just poll for readiness before.
Alternatively, we could setup the FDs ourself, and use UNIX sockets on Windows, which can be used in blocking/non-blocking mode. I haven't tried it, as I am not sure it is necessary.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20221006113657.2656108-6-marcandre.lureau@redhat.com>
show more ...
|
#
a95570e3 |
| 06-Oct-2022 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
io/command: use glib GSpawn, instead of open-coding fork/exec
Simplify qio_channel_command_new_spawn() with GSpawn API. This will allow to build for WIN32 in the following patches.
As pointed out b
io/command: use glib GSpawn, instead of open-coding fork/exec
Simplify qio_channel_command_new_spawn() with GSpawn API. This will allow to build for WIN32 in the following patches.
As pointed out by Daniel Berrangé: there is a change in semantics here too. The current code only touches stdin/stdout/stderr. Any other FDs which do NOT have O_CLOEXEC set will be inherited. With the new code, all FDs except stdin/out/err will be explicitly closed, because we don't set the flag G_SPAWN_LEAVE_DESCRIPTORS_OPEN. The only place we use QIOChannelCommand today is the migration exec: protocol, and that is only declared to use stdin/stdout.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20221006113657.2656108-5-marcandre.lureau@redhat.com>
show more ...
|
#
ec5b6c9c |
| 06-Oct-2022 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
io/command: implement support for win32
The initial implementation was changing the pipe state created by GLib to PIPE_NOWAIT, but it turns out it doesn't work (read/write returns an error). Since r
io/command: implement support for win32
The initial implementation was changing the pipe state created by GLib to PIPE_NOWAIT, but it turns out it doesn't work (read/write returns an error). Since reading may return less than the requested amount, it seems to be non-blocking already. However, the IO operation may block until the FD is ready, I can't find good sources of information, to be safe we can just poll for readiness before.
Alternatively, we could setup the FDs ourself, and use UNIX sockets on Windows, which can be used in blocking/non-blocking mode. I haven't tried it, as I am not sure it is necessary.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20221006113657.2656108-6-marcandre.lureau@redhat.com>
show more ...
|
#
a95570e3 |
| 06-Oct-2022 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
io/command: use glib GSpawn, instead of open-coding fork/exec
Simplify qio_channel_command_new_spawn() with GSpawn API. This will allow to build for WIN32 in the following patches.
As pointed out b
io/command: use glib GSpawn, instead of open-coding fork/exec
Simplify qio_channel_command_new_spawn() with GSpawn API. This will allow to build for WIN32 in the following patches.
As pointed out by Daniel Berrangé: there is a change in semantics here too. The current code only touches stdin/stdout/stderr. Any other FDs which do NOT have O_CLOEXEC set will be inherited. With the new code, all FDs except stdin/out/err will be explicitly closed, because we don't set the flag G_SPAWN_LEAVE_DESCRIPTORS_OPEN. The only place we use QIOChannelCommand today is the migration exec: protocol, and that is only declared to use stdin/stdout.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20221006113657.2656108-5-marcandre.lureau@redhat.com>
show more ...
|
#
ec5b6c9c |
| 06-Oct-2022 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
io/command: implement support for win32
The initial implementation was changing the pipe state created by GLib to PIPE_NOWAIT, but it turns out it doesn't work (read/write returns an error). Since r
io/command: implement support for win32
The initial implementation was changing the pipe state created by GLib to PIPE_NOWAIT, but it turns out it doesn't work (read/write returns an error). Since reading may return less than the requested amount, it seems to be non-blocking already. However, the IO operation may block until the FD is ready, I can't find good sources of information, to be safe we can just poll for readiness before.
Alternatively, we could setup the FDs ourself, and use UNIX sockets on Windows, which can be used in blocking/non-blocking mode. I haven't tried it, as I am not sure it is necessary.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20221006113657.2656108-6-marcandre.lureau@redhat.com>
show more ...
|
#
a95570e3 |
| 06-Oct-2022 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
io/command: use glib GSpawn, instead of open-coding fork/exec
Simplify qio_channel_command_new_spawn() with GSpawn API. This will allow to build for WIN32 in the following patches.
As pointed out b
io/command: use glib GSpawn, instead of open-coding fork/exec
Simplify qio_channel_command_new_spawn() with GSpawn API. This will allow to build for WIN32 in the following patches.
As pointed out by Daniel Berrangé: there is a change in semantics here too. The current code only touches stdin/stdout/stderr. Any other FDs which do NOT have O_CLOEXEC set will be inherited. With the new code, all FDs except stdin/out/err will be explicitly closed, because we don't set the flag G_SPAWN_LEAVE_DESCRIPTORS_OPEN. The only place we use QIOChannelCommand today is the migration exec: protocol, and that is only declared to use stdin/stdout.
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20221006113657.2656108-5-marcandre.lureau@redhat.com>
show more ...
|
Revision tags: v7.1.0, v7.1.0-rc4, v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0 |
|
#
05e50e8f |
| 25-Apr-2022 |
Marc-André Lureau <marcandre.lureau@redhat.com> |
io: make qio_channel_command_new_pid() static
The function isn't used outside of qio_channel_command_new_spawn(), which is !win32-specific.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat
io: make qio_channel_command_new_pid() static
The function isn't used outside of qio_channel_command_new_spawn(), which is !win32-specific.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
Revision tags: v7.0.0, v7.0.0-rc4, v7.0.0-rc3, v7.0.0-rc2, v7.0.0-rc1, v7.0.0-rc0, v6.1.1, v6.2.0, v6.2.0-rc4, v6.2.0-rc3, v6.2.0-rc2, v6.2.0-rc1, v6.2.0-rc0, v6.0.1, v6.1.0, v6.1.0-rc4, v6.1.0-rc3, v6.1.0-rc2, v6.1.0-rc1, v6.1.0-rc0, v6.0.0, v6.0.0-rc5, v6.0.0-rc4, v6.0.0-rc3, v6.0.0-rc2, v6.0.0-rc1, v6.0.0-rc0, v5.2.0, v5.2.0-rc4, v5.2.0-rc3, v5.2.0-rc2, v5.2.0-rc1, v5.2.0-rc0 |
|
#
e0622ae3 |
| 14-Oct-2020 |
Chetan Pant <chetan4windows@gmail.com> |
io: Fix Lesser GPL version number
There is no "version 2" of the "Lesser" General Public License. It is either "GPL version 2.0" or "Lesser GPL version 2.1". This patch replaces all occurrences of "
io: Fix Lesser GPL version number
There is no "version 2" of the "Lesser" General Public License. It is either "GPL version 2.0" or "Lesser GPL version 2.1". This patch replaces all occurrences of "Lesser GPL version 2" with "Lesser GPL version 2.1" in comment section.
Signed-off-by: Chetan Pant <chetan4windows@gmail.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
show more ...
|
#
c8198bd5 |
| 14-Oct-2020 |
Chetan Pant <chetan4windows@gmail.com> |
io: Fix Lesser GPL version number
There is no "version 2" of the "Lesser" General Public License. It is either "GPL version 2.0" or "Lesser GPL version 2.1". This patch replaces all occurrences of "
io: Fix Lesser GPL version number
There is no "version 2" of the "Lesser" General Public License. It is either "GPL version 2.0" or "Lesser GPL version 2.1". This patch replaces all occurrences of "Lesser GPL version 2" with "Lesser GPL version 2.1" in comment section.
Signed-off-by: Chetan Pant <chetan4windows@gmail.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20201014134033.14095-1-chetan4windows@gmail.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
show more ...
|
#
8063396b |
| 16-Sep-2020 |
Eduardo Habkost <ehabkost@redhat.com> |
Use OBJECT_DECLARE_SIMPLE_TYPE when possible
This converts existing DECLARE_INSTANCE_CHECKER usage to OBJECT_DECLARE_SIMPLE_TYPE when possible.
$ ./scripts/codeconverter/converter.py -i \ --patte
Use OBJECT_DECLARE_SIMPLE_TYPE when possible
This converts existing DECLARE_INSTANCE_CHECKER usage to OBJECT_DECLARE_SIMPLE_TYPE when possible.
$ ./scripts/codeconverter/converter.py -i \ --pattern=AddObjectDeclareSimpleType $(git grep -l '' -- '*.[ch]')
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Acked-by: Paul Durrant <paul@xen.org> Message-Id: <20200916182519.415636-6-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
show more ...
|
Revision tags: v5.0.1 |
|
#
8110fa1d |
| 31-Aug-2020 |
Eduardo Habkost <ehabkost@redhat.com> |
Use DECLARE_*CHECKER* macros
Generated using:
$ ./scripts/codeconverter/converter.py -i \ --pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]')
Reviewed-by: Daniel P. Berrangé <berrange@redha
Use DECLARE_*CHECKER* macros
Generated using:
$ ./scripts/codeconverter/converter.py -i \ --pattern=TypeCheckMacro $(git grep -l '' -- '*.[ch]')
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-12-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-13-ehabkost@redhat.com> Message-Id: <20200831210740.126168-14-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
show more ...
|
#
db1015e9 |
| 03-Sep-2020 |
Eduardo Habkost <ehabkost@redhat.com> |
Move QOM typedefs and add missing includes
Some typedefs and macros are defined after the type check macros. This makes it difficult to automatically replace their definitions with OBJECT_DECLARE_TY
Move QOM typedefs and add missing includes
Some typedefs and macros are defined after the type check macros. This makes it difficult to automatically replace their definitions with OBJECT_DECLARE_TYPE.
Patch generated using:
$ ./scripts/codeconverter/converter.py -i \ --pattern=QOMStructTypedefSplit $(git grep -l '' -- '*.[ch]')
which will split "typdef struct { ... } TypedefName" declarations.
Followed by:
$ ./scripts/codeconverter/converter.py -i --pattern=MoveSymbols \ $(git grep -l '' -- '*.[ch]')
which will: - move the typedefs and #defines above the type check macros - add missing #include "qom/object.h" lines if necessary
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-9-ehabkost@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-Id: <20200831210740.126168-10-ehabkost@redhat.com> Message-Id: <20200831210740.126168-11-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
show more ...
|
Revision tags: v5.1.0, v5.1.0-rc3, v5.1.0-rc2, v5.1.0-rc1, v5.1.0-rc0, v4.2.1, v5.0.0, v5.0.0-rc4, v5.0.0-rc3, v5.0.0-rc2, v5.0.0-rc1, v5.0.0-rc0, v4.2.0, v4.2.0-rc5, v4.2.0-rc4, v4.2.0-rc3, v4.2.0-rc2, v4.1.1, v4.2.0-rc1, v4.2.0-rc0, v4.0.1, v3.1.1.1, v4.1.0, v4.1.0-rc5, v4.1.0-rc4, v3.1.1, v4.1.0-rc3, v4.1.0-rc2, v4.1.0-rc1, v4.1.0-rc0, v4.0.0, v4.0.0-rc4, v3.0.1, v4.0.0-rc3, v4.0.0-rc2, v4.0.0-rc1, v4.0.0-rc0, v3.1.0, v3.1.0-rc5, v3.1.0-rc4, v3.1.0-rc3, v3.1.0-rc2, v3.1.0-rc1, v3.1.0-rc0, v3.0.0, v3.0.0-rc4, v2.12.1, v3.0.0-rc3, v3.0.0-rc2, v3.0.0-rc1, v3.0.0-rc0, v2.11.2, v2.12.0, v2.12.0-rc4, v2.12.0-rc3, v2.12.0-rc2, v2.12.0-rc1, v2.12.0-rc0, v2.11.1, v2.10.2, v2.11.0, v2.11.0-rc5, v2.11.0-rc4, v2.11.0-rc3, v2.11.0-rc2, v2.11.0-rc1, v2.11.0-rc0, v2.10.1, v2.9.1, v2.10.0, v2.10.0-rc4, v2.10.0-rc3, v2.10.0-rc2, v2.10.0-rc1, v2.10.0-rc0, v2.8.1.1, v2.9.0, v2.9.0-rc5, v2.9.0-rc4, v2.9.0-rc3, v2.8.1, v2.9.0-rc2, v2.9.0-rc1, v2.9.0-rc0, v2.7.1, v2.8.0, v2.8.0-rc4, v2.8.0-rc3, v2.8.0-rc2, v2.8.0-rc1, v2.8.0-rc0, v2.6.2, v2.7.0, v2.7.0-rc5, v2.7.0-rc4, v2.6.1, v2.7.0-rc3, v2.7.0-rc2, v2.7.0-rc1, v2.7.0-rc0 |
|
#
2a6a4076 |
| 29-Jun-2016 |
Markus Armbruster <armbru@redhat.com> |
Clean up ill-advised or unusual header guards
Cleaned up with scripts/clean-header-guards.pl.
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Richard Henderson <rth@twiddle.net>
|
Revision tags: v2.6.0, v2.5.1.1, v2.6.0-rc5, v2.6.0-rc4, v2.6.0-rc3, v2.6.0-rc2, v2.6.0-rc1, v2.6.0-rc0, v2.5.1 |
|
#
821791b5 |
| 13-Jan-2016 |
Daniel P. Berrange <berrange@redhat.com> |
io: fix description of @errp parameter initialization
The "Error **errp" parameters must be NULL initialized not uninitialized.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
|
Revision tags: v2.5.0, v2.5.0-rc4, v2.5.0-rc3, v2.5.0-rc2, v2.5.0-rc1, v2.5.0-rc0, v2.4.1, v2.4.0.1 |
|
#
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 ...
|