The Windows printf functions don't support %llu/%lld for printing 64-bit
integers. For most of libvirt this doesn't matter as we rely on gnulib
which provides a replacement printf that is sane.
The example code is designed to compile against the normal OS headers,
with no use of gnulib and thus has to use the platform specific printf.
To deal with this we must use the macros PRI* macros from inttypes.h
to get the platform specific format string.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
mingw lacks sigaction(); we were getting it from gnulib. But since
commit acf522e8 stopped linking examples against gnulib, we are
getting a build failure. Keep the examples standalone, and work
around mingw by using signal() instead.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
mingw lacks %lld and %zu support in printf(); we were getting it
from gnulib. But since commit acf522e8 stopped linking examples
against gnulib, we are getting a build failure due to -Wformat
flagging these strings. Keep the examples standalone, and work
around mingw by using manual casts to types we can portably print.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Commit 0c6ad476 updated gnulib, which rearranged some of the
conditions in gnulib wrapper headers such that compilation
started failing on BSD systems when the normal system <unistd.h>
tried to include another system header but instead got a
gnulib wrapper header in an incomplete state; this is because
gnulib headers only work if <config.h> is included first.
Commit b6f78259 papered over the symptoms of that by including
<config.h> in all the examples. But this logic is backwards -
if our examples are truly meant to be stand-alone, they should
NOT depend on how libvirt was configured, and should NOT
depend on the gnulib fixes for system quirks. In particular,
if an example does not need to link against libgnulib.la,
then it also does not need to use -Ignulib in its compile
flags, and likewise does not need to include <config.h> since
none of the gnulib wrapper headers should be interfering.
So, revert (most of) b6f78259 (except for the bogus pre-patch
use of "config.h" in admin/logging.c: if config.h is included,
it should be via <> rather than "", and must be before any
system headers); then additionally nuke all mention of
<config.h>, -Ignulib, and -llibgnu.la, making all of the
examples truly standalone.
Signed-off-by: Eric Blake <eblake@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In many files there are header comments that contain an Author:
statement, supposedly reflecting who originally wrote the code.
In a large collaborative project like libvirt, any non-trivial
file will have been modified by a large number of different
contributors. IOW, the Author: comments are quickly out of date,
omitting people who have made significant contribitions.
In some places Author: lines have been added despite the person
merely being responsible for creating the file by moving existing
code out of another file. IOW, the Author: lines give an incorrect
record of authorship.
With this all in mind, the comments are useless as a means to identify
who to talk to about code in a particular file. Contributors will always
be better off using 'git log' and 'git blame' if they need to find the
author of a particular bit of code.
This commit thus deletes all Author: comments from the source and adds
a rule to prevent them reappearing.
The Copyright headers are similarly misleading and inaccurate, however,
we cannot delete these as they have legal meaning, despite being largely
inaccurate. In addition only the copyright holder is permitted to change
their respective copyright statement.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Right-aligning backslashes when defining macros or using complex
commands in Makefiles looks cute, but as soon as any changes is
required to the code you end up with either distractingly broken
alignment or unnecessarily big diffs where most of the changes
are just pushing all backslashes a few characters to one side.
Generated using
$ git grep -El '[[:blank:]][[:blank:]]\\$' | \
grep -E '*\.([chx]|am|mk)$$' | \
while read f; do \
sed -Ei 's/[[:blank:]]*[[:blank:]]\\$/ \\/g' "$f"; \
done
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
For instance:
hellolibvirt/hellolibvirt.c: In function 'showDomains':
hellolibvirt/hellolibvirt.c💯19: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
for (i = 0; i < numNames; i++) {
^
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Using one Makefile per example subdirectory essentially serializes 'make'
calls. Convert to one example/Makefile that builds and distributes
all the subdir files. This reduces example/ rebuild time from about 5.8
seconds to 1.5 seconds on my machine.
One slight difference is that we no longer ship Makefile.am with the
examples in the rpm. This was virtually useless anyways since the Makefile
was very specific to libvirt infrastructure, so wasn't generically
reusable anyways.
Tested with 'make distcheck' and 'make rpm'
So, in the example the cpu stats are collected within a function
called do_top. At the beginning of the function we ask the daemon for
how much vCPUs can we get stats, and how many stats for a vCPU can we
get. This is because it's how our API works - users are required to
preallocate a chunk of memory for the results. Now, at the end, we try
to free the allocated array, but we are not doing it correctly.
There's this virTypedParamsFree() function which gets a pointer to the
array and the length of the array. However, if there was an error in
getting vCPU stats we pass a negative number instead of the originally
computed value. This flaw results in SIGSEGV:
libvirt: QEMU Driver error : Requested operation is not valid: domain is not running
ERROR do_top:333 : Unable to get cpu stats
==29201== Invalid read of size 4
==29201== at 0x4F1DF8B: virTypedParamsClear (virtypedparam.c:1145)
==29201== by 0x4F1DFEB: virTypedParamsFree (virtypedparam.c:1165)
==29201== by 0x4023C3: do_top (domtop.c:349)
==29201== by 0x40260B: main (domtop.c:386)
==29201== Address 0x131cd7c0 is 16 bytes after a block of size 768 alloc'd
==29201== at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==29201== by 0x401FF1: do_top (domtop.c:295)
==29201== by 0x40260B: main (domtop.c:386)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The variable 'k' in the print_cpu_usage function is not used anywhere
and can fire a warning on some compilers.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Currently, the function follows the usual pattern used in our code:
int ret = -1;
...
ret = 0;
cleanup:
return ret;
However, the function always call exit() on error, so the cleanup
label is never jumped onto. Therefore, it doesn't make any sense to
have the parse_argv function return an integer value, if it
effectively can return only value of zero.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Firstly, there's no sigaction() nor struct sigaction on mingw. We have
to use the one implemented by gnulib (and hence link with gnulib).
Then, for some reason one header file from windows defines ERROR
symbol. Yes it does. Sigh.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Use the virTypedParamsFree unconditionally as it handles NULL well and
has the benefit of freeing a typed parameter array even if it wasn't yet
assigned, but only allocated.
There's this question on the list that is asked over and over again.
How do I get {cpu, memory, ...} usage in percentage? Or its modified
version: How do I plot nice graphs like virt-manager does?
It would be nice if we have an example to inspire people. And that's
what domtop should do. Yes, it could be written in different ways, but
I've chosen this one as I think it show explicitly what users need to
implement in order to imitate virt-manager's graphing.
Note: The usage is displayed from host perspective. That is, how much
host CPUs the domain is using. But it should be fairly simple to
switch do just guest CPU usage if needed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
