Validate also variables exported as 'extern' e.g. from the util
submodule.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When commit d249170bf6 modified the arguments of
'virNetTLSContextNew' which has a systemtap probe defined the
'dtrace2systemtap' script was no longer to correctly generate the
definitions for it.
First problem which stemmed from mis-detecting the string array
argumment as string, which would use 'user_string' to extract it was
fixed in cb33103c4a.
After that the generated probe is still not correct because it doesn't
strip all the '*' from pointers and thus for double pointers it
generates the following invalid definition:
probe libvirt.rpc.tls_context_new = process("/usr/lib64/libvirt.so").mark("rpc_tls_context_new") {
ctxt = $arg1;
cacert = user_string($arg2);
cacrl = user_string($arg3);
*cert = $arg4;
*keys = $arg5;
sanityCheckCert = $arg6;
requireValidCert = $arg7;
isServer = $arg8;
}
Leading to the following failure:
# stap -ve 'probe oneshot {exit()}'
parse error: expected literal string or number
saw: operator '*' at /usr/share/systemtap/tapset/libvirt_probes-64.stp:204:3
source: *cert = $arg4;
^
1 parse error.
To address the issue the regex extracting the arguments needs to
optionally match any number of '*' instead of just one.
Resolves: https://issues.redhat.com/browse/RHEL-153832
Fixes: cb33103c4a
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
We've been using glib g_setenv() since commit
2c33532423 in December 2019 (switching
away from the gnulib version of setenv()). Most (but not all) of the
calls to get environment variables have remained using libc's getenv()
though, even though there is a g_getenv() wrapper in glib to match the
g_setenv() wrapper.
While getenv() doesn't have the thread safety problems of setenv(),
it's still recommended that users of g_setenv() also use g_getenv()
(for consistency, and because the glib functions handle UTF-8 properly
while libc getenv() may or may not depending on the setting of LANG in
the environment).
This patch changes all calls to getenv() to use g_getenv() instead,
with the exceptions of:
1) the call to getenv() in virt-login-shell.c (because
virt-login-shell runs setuid root, and we don't want glib or any other
gigantic library anywhere near a setuid program). In a few cases a
char * needs to be made const, and the return from getenv() needs to
be g_strdup()ed if it must stick around for any amount of time (since
the buffer returned from g_getenv() might be recycled/re-used if there
is another call to g_getenv()/g_setenv()).
2) the call to getenv() in libvirt_nss_log.c because it is compiled
into a loadable module that will be loaded into a process after the
process's normal startup, and so any initialization that might be
required for a glib function to operate properly may not be called.
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When a probe argument is declared "char *" we reference the userspace
string value using 'user_string(...)' for systemtap.
Unfortunately our code generator also matches on args declared "char **"
and generates bogus code
*cert = user_string($arg4);
which is a syntax error for systemtap.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In previous commit of v12.0.0-85-g2c66b6d72c we've tried to solve
a problem where xdrproc_t is a prototype of a function which
takes only two arguments instead of three. See original commit
for more info. The fix consists of a config time check and
setting XDRPROC_T_3ARGS accordingly (in meson-config.h). This
works for nearly all of our code, except rpcgen which is
intentionally independent of the rest of the code. Therefore, the
macro has to be set extra - by specifying it on the compiler cmd
line.
Fixes: 2c66b6d72c
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
According to 9fa3a8ab6f,
macOS insists on passing 3 arguments for xdrproc_t.
Passing 3 arguments was a good common ground, but since
recently[1] FreeBSD only accepts 2 arguments.
Add a meson.build check whether 3 arguments are accepted,
and add macros which passes either 2 or 3 arguments to
xdrproc_t based on the result of this check.
1: https://cgit.freebsd.org/src/commit/?id=ac5a19ec6989675c8ec6c3ca245dba243d1a6416
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Passing warning flags to the C compiler results in incredibly long
command lines, which in turns results in incredibly large CI log
files. Our logs are so large that they often exceed the GitLab
file limits.
We've cut out the irrelevant cruft from the logs and they're still
too large. The only option left is to stop passing so many args
to the compiler.
Fortunately it is easy to achieve this with GCC/CLang as when seeing
an argument "@somepath" they will treat each line in "somepath" as
being an additional compiler argument.
Putting the warning flags in a 'c-warnings.txt' file is fairly
easy and a massive win. We don't lose anything from the CI logs
as we print the full set of warning flags at the end of running
'meson'. Meanwhile for interactive builds the flags are visible
in the c-warnings.txt file in the build directory root.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
A previous commit removed the 'ret' variable when
switching to subprocess.run, but did not adjust
the exit code.
Fixes: 15c9ca383c
Signed-off-by: Ján Tomko <jtomko@redhat.com>
The subprocess.run command avoids using the shell and so is robust
should sys.argv contain any whitespace or unexpected shell meta
characters.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In a recent refactor the block of code outputting device properties was
mis-indented causing it to only work on device properties which have no
'default-value'.
Fixes: 301e1ba244
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This is useful for checking that the script still covers everything when
using it to compare two .replies files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While 'query-command-line-options' is usually fairly stable (for
comparing between two .replies files) it's simpler to compare it in the
dumped variant.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Process few other simple commands. While this output doesn't change
places it's useful to see it when comparing the dumps of two .replies
files.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The --dump-* mode can be used together with --repliesdir which iterates
over all '.replies' files in the directory. Make this useful by
outputing the filename so the user can associate the data with the file
it was dumped from.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In addition to 'device-list-properties' libvirt probes also some
properties of qom types. Since the format is identical make the dumping
function for 'device-list-properties' universal and make it accept also
'qom-list-types'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Dumps the supported machine types and their deprecation state in stable
human-sort order.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
While '--dump-qmp-query-strings' is useful by itself because it's a
simple way to generate the QMP schema query strings for libvirt, the
other modes aren't useful besides comparing two .replies files by the
dumped output.
Remove specific options for '--dump-qom-list-types' and
'--dump-device-list-properties', so that upcoming additions which will
be useful only for comparisons aren't forced to add these options.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently the conversation was a list of tuples. Since upcoming patches
will want to store some additional flags with the processed commands
convert it to a list of dicts, so that we can name the individual
fields.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Similar branches in the if-else structure look like bad copy-paste.
Fix the typo.
Fixes: a559ffec44 (src: rewrite ACL rule checker in Python)
Signed-off-by: Elizaveta Tereshkina <etereshkina@astralinux.ru>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The script is renamed to mockable-attribute.py and adjusted to
check for the new attribute.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Currently, if we want to mock a function the noinline attribute
is appended after the function (via G_NO_INLINE macro). This used
to work for non pure functions. But there are some trivial
functions (for instance virQEMUCapsProbeHVF()) that are pure,
i.e. have no side effect, and while their call from other parts
of the code is not optimized out, their call from within the same
compilation unit (qemu_capabilities.c) is optimized out.
This is because inlining and semantic interposition are two
different things. Even GCC's documentation for noinline attribute
[1] states that clearly:
This function attribute prevents a function from being
considered for inlining. It also disables some other
interprocedural optimizations; it’s preferable to use the more
comprehensive noipa attribute instead if that is your goal.
Even if a function is declared with the noinline attribute,
there are optimizations other than inlining that can cause
calls to be optimized away if it does not have side effects,
although the function call is live.
Unfortunately, despite attempts [2] Clang still does not support
the attribute and thus we have to rely on noinline +
-fsemantic-interposition combo.
1: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noinline-function-attribute
2: https://reviews.llvm.org/D101011
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The mock-noinline.py script is fed list of files through its
stdin, each file on its own line. Unfortunately, the way the
script is written does nothing as the trailing newline character
prevents any .endswith() match. Strip each line of white spaces.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
If a variable is not modified in a scope there is no need for the use of
global in such scope. Without this patch build fails with:
F824 `global ...` is unused: name is never assigned in scope
It is a bit difficult to find more information on that message and error
code, I found it here:
https://docs.astral.sh/ruff/rules/global-variable-not-assigned/
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Introduce a new ninja target
ninja -C build regen-{PROTO}
eg
ninja -C build regen-admin_protocol
that will re-create the reference output file based on what the
current pdwtags command emits. A small change is made to squash
whitespace on enum declarations so that introducing a new longer
enum name doesn't trigger re-indent of all existing enum names.
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Most, but not all, files in scripts have execute permission. While we
don't need this in order to launch them via meson/ninja build rules,
it is nice to direct execution if they have execution permission. This
makes the practice consistent across all scripts.
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The query language allows querying whether a member is optional by using
the '*' "operator" but the dumper script didn't output those query
strings.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Enforce that relative links are used within the page, so that local
installations don't require internet conection and/or don't redirect to
the web needlessly.
This is done by looking for any local link (barring exceptions) when
checking links with 'check-html-references.py'.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Add a '--require-https' switch to 'check-html-references' helper script
which will error out if any non-https external link is used from our web
and use it while builidng docs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This skips building tests which rely on tirpc when it is not
present.
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Since header file structure is a bit different on MacOS, it
doesn't get uint64_t type declaration and thus test_demo.c must
include it explicitly. This is proper solution anyway, because on
Linux we're apparently relying on the header file sneaking
through some other include.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/619
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The order of properties in 'device-list-properties' can hange
arbitrarily and git is not great at picking the contexts in JSON to help
seeing what changed.
The new --dump-device-list-properties produces a stable order of
properties and dumps also the type and default value mainly useful for
comparing two .replies files.
Example output:
$ ./scripts/qemu-replies-tool.py tests/qemucapabilitiesdata/caps_9.0.0_x86_64.replies --dump-device-list-properties
(dev) ICH9-LPC acpi-index uint32 (0)
(dev) ICH9-LPC acpi-pci-hotplug-with-bridge-support bool
(dev) ICH9-LPC acpi_disable_cmd uint8
(dev) ICH9-LPC acpi_enable_cmd uint8
(dev) ICH9-LPC addr int32 (-1)
(dev) ICH9-LPC cpu-hotplug-legacy bool
(dev) ICH9-LPC disable_s3 uint8
(dev) ICH9-LPC disable_s4 uint8
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The order of entries in 'qom-list-types' sometimes changes arbitrarily.
The --dump-qom-list-types produces a stable order and drops the for
libvirt unneeded 'parent' information.
Sample output:
$ ./scripts/qemu-replies-tool.py tests/qemucapabilitiesdata/caps_9.0.0_x86_64.replies --dump-qom-list-types
(qom) 486-v1-x86_64-cpu
(qom) 486-x86_64-cpu
(qom) AC97
(qom) AMDVI-PCI
(qom) Broadwell-IBRS-x86_64-cpu
(qom) Broadwell-noTSX-IBRS-x86_64-cpu
(qom) Broadwell-noTSX-x86_64-cpu
(qom) Broadwell-v1-x86_64-cpu
(qom) Broadwell-v2-x86_64-cpu
(qom) Broadwell-v3-x86_64-cpu
[...]
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Make the tool useful also for non-testing purposes by adding 'dump'
mode, which will process the data and output information about the qemu
version.
The first 'dump' mode produces all possible valid query strings per
virQEMUQAPISchemaPathGet/virQEMUCapsQMPSchemaQueries. This is useful for
users to look up a query string via 'grep' rather than trying to come up
with it manually.
Additionally the data as represented by qemu changes naming very often
and that makes it un-reviewable to find changes between two qemu builds.
By using the dump mode, which produces results in stable order we can
use it to 'diff' two .replies file without churn.
Sample output '[...]' denotes an arbitrary trim:
$ ./scripts/qemu-replies-tool.py tests/qemucapabilitiesdata/caps_9.0.0_x86_64.replies --dump-qmp-query-strings
[...]
(qmp) blockdev-add
(qmp) blockdev-add/arg-type/auto-read-only
(qmp) blockdev-add/arg-type/auto-read-only/!bool
(qmp) blockdev-add/arg-type/cache
(qmp) blockdev-add/arg-type/cache/direct
(qmp) blockdev-add/arg-type/cache/direct/!bool
(qmp) blockdev-add/arg-type/cache/no-flush
(qmp) blockdev-add/arg-type/cache/no-flush/!bool
(qmp) blockdev-add/arg-type/detect-zeroes
(qmp) blockdev-add/arg-type/detect-zeroes/^off
(qmp) blockdev-add/arg-type/detect-zeroes/^on
(qmp) blockdev-add/arg-type/detect-zeroes/^unmap
[...]
(qmp) blockdev-add/arg-type/driver
(qmp) blockdev-add/arg-type/driver/^blkdebug
(qmp) blockdev-add/arg-type/driver/^blklogwrites
(qmp) blockdev-add/arg-type/driver/^blkreplay
(qmp) blockdev-add/arg-type/driver/^blkverify
(qmp) blockdev-add/arg-type/driver/^bochs
(qmp) blockdev-add/arg-type/driver/^cloop
[...]
(qmp) blockdev-add/arg-type/+blkdebug
(qmp) blockdev-add/arg-type/+blkdebug/align
(qmp) blockdev-add/arg-type/+blkdebug/align/!int
(qmp) blockdev-add/arg-type/+blkdebug/config
(qmp) blockdev-add/arg-type/+blkdebug/config/!str
(qmp) blockdev-add/arg-type/+blkdebug/image
(qmp) blockdev-add/arg-type/+blkdebug/image (recursion)
(qmp) blockdev-add/arg-type/+blkdebug/image/!str
(qmp) blockdev-add/arg-type/+blkdebug/inject-error
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
If the schema itself is extended in qemu we need to have a notification
to add appropriate handling to ensure that we have full coverage of all
fields.
Add validation that only fields that libvirt currently knows about are
present in the schema.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The tool in the current shape functionally replaces
tests/qemucapabilitiesnumbering.c
It validates that the output '.replies' files conform to how we generate
them from qemu and also allows programmatic modification of the
'.replies' files if re-generation is not feasible any more.
The main advantage is that JSON objects are parsed into native python
types and thus the programatic modification is much more convenient.
The tool will be later extended to also do validation that we properly
handle the whole of QMP schema as well as help in reviewing the
differences in the .replies file after qemu updates.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The script expects each of the symbols that it looks for to
be in one of three sections, which in nm(1) are described as
follows:
T - The symbol is in the text (code) section.
B - The symbol is in the BSS data section. This section
typically contains zero-initialized or uninitialized
data, although the exact behavior is system dependent.
D - The symbol is in the initialized data section.
When building on alpha, however, some of the symbols show up
in one of two additional sections, specifically:
S - The symbol is in an uninitialized or zero-initialized
data section for small objects.
G - The symbol is in an initialized data section for small
objects.
In other words, S is the same as B and G is the same as D,
except with some optimization for small objects that for some
reason is applied on alpha but not on other architectures.
I have confirmed that, for all the symbols that the script
complained about being missing on alpha, the section is the
expected one, that is, symbols that are reported as B on x86
are reported as S on alpha, and symbols that are reported as
D on x86 are reported as G on alpha.
Note that, while the B section doesn't seem to be used at all
on alpha, at least in our case, the D section still is.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The generator can produce different code on Linux and macOS:
specifically, on the former we want to use xdr_uint64_t while
the latter needs xdr_u_int64_t instead.
This is clearly a problem for tests that involve comparing the
output produced against some expected output that's stored in
the git repository.
In the long run, we need to find a better way to handle this,
but since 9.10.0 is going to be released very soon and we don't
want it to have a broken test suite on macOS, simply skip the
generator tests on that platform for now.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
macOS XDR library is an oddball using xdr_u_int64_t instead of
xdr_uint64_t which everyone else has.
The code generator already does the right thing, but the test
program previously generated with the Linux rpcgen program
does not compile on macOS due to this.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The test_demo program currently fails to compile on macOS with
too few arguments to function call, expected 3, have 2
ret = !!proc(&xdr, vorig);
~~~~ ^
Way back in 2013, commit 9fa3a8ab6f handled this situation
for the main library code. Apply the same fix here.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
These are currently the only tests that are not part of any
suite.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Some of the files used by test_demo.c can only be regenerated
when pytest is present, but we have pre-generated copies in the
repository, so overall we just need the C compiler to build and
run that specific test program.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
There are some platforms where 'char' is unsigned, by default
(RPi, s390x to name a few). And because of how test_demo is
written we are experiencing some test cases failing there. For
instance: /xdr/struct-scalar is failing. This is because in the
test (test_struct_scalar()), we have a struct with two chars. One
is initialized to 0xca, the other 0xfe (note that both have the
MSB set). The XDR encoder (xdr_TestStructScalar()) then calls
xdr_char() on both of them. But XDR itself has no notion of
char type, so under the hood, it expands it to int [1] and calls
xdr_int(). And this is where the problem lies. On platforms where
char is signed, the integer expansion results in 0xffffffca, but
on platforms where char is unsigned it results in 0x000000ca. Two
distinct results.
The test then goes and compares the encoded buffer with an
expected one (memcmp(), read from the disk earlier).
This poses no problem for real life use, because when decoding
those chars back, the padding is thrown away.
To avoid tickling this issue, use values that don't have the MSB
set.
1: https://git.linux-nfs.org/?p=steved/libtirpc.git;a=blob;f=src/xdr.c;h=28d1382cc4853ecf1238d792af5016160435d1e0;hb=HEAD#l487
Fixes: 40cbaa8fbe rpcgen: add test case for XDR serialization
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
The test_demo program compares whether XDR encoded data match the
expected output as read from a file. But the file path is not
absolute and thus relative to CWD which means the program can run
only from one specific directory.
Do what we do in the rest of our test suite: define 'abs_srcdir'
macro and prefix the path with it.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
flake8 (run on all python scripts as a part of the syntax checks)
version 6.1.0 (on macOS 14) issued many complaints like this on the
new rpcgen python scripts:
[...]libvirt/scripts/rpcgen/rpcgen/lexer.py:57:17: E721 do not compare types, for exact checks use `is` / `is not`, for instance checks use `isinstance()`
This patch changes all [type] == [type] to use "is" instead of "==",
and similarly to use "is not" instead of "!=".
(flake8 5.03, e.g. on Fedora 38, is just fine with using "==" and "!=",
but python on both likes "is" and "is not")
Fixes: commit v9.9.0-24-g8ec79e5e14
Fixes: commit v9.9.0-22-gca3f025011
Fixes: commit v9.9.0-21-g031efb691f
Fixes: commit v9.9.0-20-g8c8b97685b
Signed-off-by: Laine Stump <laine@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This will eliminate the need to call xdr_free to clear
pointers from data structures.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This replaces use of 'rpcgen' with our new python impl of
the RPC code generator. Since the new impl generates code
that matches our style/coding rules, and does not contain
long standing bugs, we no longer need to post-process the
output.
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Peter Krempa
Laine Stump
Daniel P. Berrangé
Michal Privoznik
Roman Bogorodskiy
Ján Tomko
Elizaveta Tereshkina
Martin Kletzander
Andrea Bolognani