Isolate the logic for the memoized disk cache in a small module, so it
can be reused for other tools.
Other than refactoring, there should be no behaviour changes.
- fix names of arguments & optional arguments in C<..> markers
- use https for URLs where possible
- fix links to other guestfs APIs
- use more C<..> markers for special tests, shell commands, values of
arguments, and names of fields
- link to command man pages where an explicit command is mentioned
- fix few incorrect documentation bits
Without clarifying handle's lifetime, it is unable
to see how long the callbacks which the handle
owns will live. Then, Rust compiler will infer
that the callbacks have 'static lifetime. It is
not convenient for users.
Soon only the virt-p2v authors will be available, so remove all the
other roles. This leaves only in the virt-p2v about dialog, which is a
mild regression compared to the current situation, although it is just
for user information.
Copy from generator/p2v_config.ml also the bits for POD documentation,
adding them to generate-p2v-config.pl; this way,
virt-p2v-kernel-config.pod can be generated at build time directly,
instead of statically shipped as generator output.
Instead of generating the p2v kernel config using the OCaml generator,
create a Perl script to do this job, mostly at build time. This is done
to rely less on the generator for p2v, and because the generation of
these sources is quick enough that it can be done at build time (instead
of shipping the generated sources in dist tarballs).
The generate-p2v-config.pl mimics what generator/p2v_config.ml --
namings, and general structure are kept close to that for comparison.
The two C sources are created at build time by the script; however, the
p2v-config.h header is generated at configure time: this is done because
p2v-config.h is included by p2v.h (another header), which in turn is
included by all the p2v C sources -- automake is not able to properly
resolve the dependency, and thus it would not be generated properly.
Add a simple way to do not even provide prototypes of deprecated
functions in the C library: this way, users (like our tools) can build
against the library making sure to not use any deprecated function, not
even when compiler deprecation warnings are disabled.
Add it to the majority of our tools/internal libraries, and make sure
that it is not defined when building the API bridges of our bindings.
Right now, deprecated functions of the library do not trigger any
compiler deprecation warning by default; they do that only if
GUESTFS_WARN_DEPRECATED=1 is defined. However, this is not something
that seems to be done often -- at least none of the projects using the
libguestfs C API does that.
Hence, do a small behaviour change to change this on the other way
round: now deprecated functions trigger compiler deprecation warnings by
default, using GUESTFS_NO_WARN_DEPRECATED to disable this (and revert
to the previous behaviour). Even though deprecated functions will not
be removed, we really want users to migrate away from them, as they were
deprecated for good reasons.
Define GUESTFS_NO_WARN_DEPRECATED where needed:
- in all the bindings, as they bind all the functions including the
deprecated ones
- in the guestfish actions, as it exposes almost all the APIs
- in the C API test, as it runs the automated tests of all the APIs that
have them
- for two tests that explicitly test deprecated functions
So far RBufferOut return values, and FBuffer struct fields are 'str' on
all the versions of Python. Python 3 distinguishes between 'str'
(unicode strings), and 'bytes', with 'str' no more able to hold
arbitrary data.
For this reason, switch the return value of RBufferOut functions, and
FBuffer struct fields to bytes on Python 3: while this is a potentially
incompatibile change, this is the only way to handle safely sequences
of arbitrary bytes.
After this commit, all annocheck errors are fixed except for:
Hardened: virt-get-kernel: MAYB: Gaps were detected in the annobin coverage. Run with -v to list.
After discussion with the annocheck maintainers this gap in coverage
(which corresponds to the OCaml runtime) seems to be caused either by
the runtime not being linked with the right flags, or might be a bug
in annocheck itself. In any case it's not something that can be
resolved within the scope of libguestfs.
This change helps to make libguestfs package build reproducible.
See https://reproducible-builds.org/ for why this is good.
Without this patch, building today's libguestfs in 2033, claims
Copyright (C) 2009-2033 Red Hat Inc.
which cannot be correct.
This affected files like
/usr/include/guestfs-gobject.h
/usr/lib/perl5/vendor_perl/5.26.2/x86_64-linux-thread-multi/Sys/Guestfs.pm
/usr/lib64/python2.7/site-packages/guestfs.py
/usr/lib64/ocaml/guestfs/guestfs.mli
Commits like 212762c593
will take care of updating the year.
When erroring out about duplicated parameters, say "more than once"
instead of "twice", since there can be more than two repeated
parameters.
Thanks to: Xiaodai Wang
As a side effect, a lot more fields are now settable on the
kernel command line.
Existing kernel command lines & corresponding documentation should
still remain backwards compatible.
Since the previous commit introduced configuration sections, we can
now group more configuration settings together in these sections.
The largest part of this commit is a simple renaming of fields in the
struct.
Mostly refactoring to make it easier to add fields to this struct in
future.
I'd like to call the header p2v/config.h but that's not possible since
it conflicts with the autoconf-generated file.
The old vgscan API literally ran vgscan. When we switched to using
lvmetad (in commit dd162d2cd5) this
stopped working because lvmetad now ignores plain *scan commands
without the --cache option.
We documented that vgscan would rescan PVs, VGs and LVs, but without
activating them.
I have introduced a new API (lvm_scan) which scans or rescans PVs, VGs
and LVs. It has an optional activate parameter allowing activation of
any new LVs that are found.
With lvmetad this nicely maps to the single command:
pvscan --cache [--activate ay]
Use the cleanup handlers to free the structs (and list of structs) in
case their OCaml->C transformation fails for any reason; use calloc()
to not try to use uninitialized memory.
In case of lists, avoid allocating the memory for the array if there
are no elements, since the returned pointer in that case is either NULL,
or a free()-only pointer; also, set the list size only after the array
is allocated, to not confuse the XDR routines.
Instead of parsing 'parted' output OCaml implementation relies on the following facts:
1. MBR partition table can hold up to 4 "primary" partitions.
2. Partition with number greater then 4 is "logical" partition.
3. Partition with number less then or equal to 4 with MBR ID 0x05 or 0x0f is "extended" partition (http://thestarman.pcministry.com/asm/mbr/PartTypes.htm; https://en.wikipedia.org/wiki/Partition_type) or "primary" otherwise.
Some filesystems fall back silently to read-only if there are problems
such a dirty filesystem and an unrecoverable journal. Almost all
conversions involve writing to the root filesystem, so these will
inevitably fail later on with a strange error message.
Test the root filesystem is writable by creating and deleting a
temporary file, and if the creation fails then give better
diagnostics.
Reported-by: Piotr Kliczewski
The guestfish prepared disks (-N option) all defaulted to 100M. This
has always been too small for btrfs (so for example ‘-N fs:btrfs’ has
failed for a long time), and can be too small for LVs with new LVM2 /
kernel >= 4.16.
This changes the default from 100M to 1G. The beginning of the 1.39
branch seems like a good time to make this change.
Add a way to generate OCaml interfaces for all the modules in the
daemon that implement APIs: this makes sure that for them the
interface of each function matches the actual API specified in the
generator.
When checking the return value of guestfs_int_py_fromstring for string
fields of structs, add a newline to generated C code, so it is properly
indented.
Fixes commit 401c445636.
An installation of MS-DOS has various files in a /DOS directory,
which COMMAND.COM looking like a reasonable signal that its MS-DOS
or a very close relative there-of.
This is validated with an MS-DOS 6.22 install.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
