There's no particular reason that we have to update these files in
every 'make'. It's slow, and it doesn't really matter if a single
file is accidentally omitted from translations on a developer's build
machine.
On the other hand generating it from 'make dist' has advantages:
- We only do it once per release.
- The maintainer can check the changes carefully.
- If a developer adds some random files in their local build tree,
these won't be picked up accidentally.
- Changes to POTFILES etc won't leak into general commits.
Add the real list of C source files to the Makefile, instead of trying
to calculate it. This (will, in the next commit) fix a problem with
the build on Koji where we created a subdirectory (for python3/) but
the find command picked up files from that directory for the
documentation (and then failed).
This fixes commit 04229c68d6.
As in libvirt, allow internal documentation comments in C files.
These are marked using '/**' comments. Unlike libvirt which has an
ill-defined and inconsistent markup, the markup we use is Perl POD.
These comments are added to guestfs-internals(1), but are most likely
to be read in-place.
This commit changes some existing comments in src/launch.c to
demonstrate how this can be used.
Refactor registry patching to share common parts between Win <= 7 and
Win >= 8. Also branch between the two based on the presence of the
DriverDatabase subtree rather than on the OS version, which allows not
to pass the inspect handle into the functions.
OTOH make the patching functions accept the driver name and device PCI
id as arguments; this will allow to easily expand the code to support
other drivers (e.g. vioscsi) later on.
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
It turned out (by trial and error) that for Windows >= 8 / 2012, even
though the PnP system uses names related to the original driver's .inf
file for certain entries under DriverDatabase registry subtree, this
doesn't have to hold for the storage driver to make it boot.
So use our own artificial names there and simplify the surrounding code.
This will also make sure the added entries don't confilct with those
generated by PnP proper once the driver is installed, and that the
entries are easy to look up in the eventual registry.
The name chosen to refer to the driver -- "guestor" -- is intentionally
different from the original "viostor" both to avoid collisions and to
naturally expand to other relevant drivers (e.g. "vioscsi") later on.
Tested on
Win 8 x32
Win 8 x64
Win 8.1 x32
Win 8.1 x64
Win 2012R2 x64
Win 10 x64
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
The patch to the Windows registry allowing it to boot off a virtio-blk
drive was initially conceived by comparing the state with virtio-blk
driver properly installed, to that without.
However, we don't want to replicate the Windows PnP system; rather we
need to apply just enough edits to make the system boot, and then let
the Windows PnP manager figure out the rest.
It turned out (by trial and error) that for Windows >= 8 / 2012 the
"just enough" set includes only the service entry for the driver, and a
few entries under DriverDatabase.
Tested on
Win 8 x32
Win 8 x64
Win 8.1 x32
Win 8.1 x64
Win 2012R2 x64
Win 10 x64
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
The patch to the Windows registry allowing it to boot off a virtio-blk
drive was initially conceived by comparing the state with virtio-blk
driver properly installed, to that without.
However, we don't want to replicate the Windows PnP system; rather we
need to apply just enough edits to make the system boot, and then let
the Windows PnP manager figure out the rest.
It turned out that for Windows <= 7 / 2008R2 the "just enough" set
includes only the service entry for the driver, and a
CriticalDeviceDatabase entry matching the PCI id of the device and
pointing at that service entry.
While at this, also drop CriticalDeviceDatabase entries for older and
no longer relevant PCI ids of the virtio-blk device.
Tested on
Win XP SP3 x32
Win XP SP2 x64
Win 2003R2 SP2 x32
Win 2003R2 SP2 x63
Win Vista SP2 x32
Win Vista SP2 x64
Win 2008 SP2 x32
Win 2008R2 SP1 x64
Win 7 SP1 x32
Win 7 SP1 x64
Signed-off-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: "Richard W.M. Jones" <rjones@redhat.com>
Adapt to the API changes in the newer versions of the Zend framework, in
particular regarding:
- strings handling
- resources handling (used for the guestfs_h pointer)
- iterating in hash maps
- data types for function arguments
Introduce helper macros to reduce greatly the amount of #if's all around
the generated C code.
In the generated description of the guestfish commands, wrap and indent
the help text, so it is a multiline string instead of a very long single
one.
This has no behaviour changes, only makes cmds.c more readable (and
easier to diff when the description of actions change).
Like with the previous commit, this replaces instances of:
if (something_bad) {
fprintf (stderr, "%s: error message\n", guestfs_int_program_name);
exit (EXIT_FAILURE);
}
with:
if (something_bad)
error (EXIT_FAILURE, 0, "error message");
(except in a few cases were errno was incorrectly being ignored, in
which case I have fixed that).
It's slightly more complex than the previous commit because we must be
careful to:
- Remove the program name (since error(3) prints it).
- Remove any trailing \n character from the message.
Candidates for replacement were found using:
pcregrep --buffer-size 10M -M '\bfprintf\b.*\n.*\bexit\b' `git ls-files`
Wherever we had code which did:
if (something_bad) {
perror (...);
exit (EXIT_FAILURE);
}
replace this with use of the error(3) function:
if (something_bad)
error (EXIT_FAILURE, errno, ...);
The error(3) function is supplied by glibc, or by gnulib on platforms
which don't have it, and is much more flexible than perror(3). Since
we already use error(3), there seems to be no downside to mandating it
everywhere.
Note there is one nasty catch with error(3): error (EXIT_SUCCESS, ...)
does *not* exit! This is also the reason why error(3) cannot be
marked as __attribute__((noreturn)).
Because the examples can't use gnulib, I did not change them.
To search for multiline patterns of the above form, pcregrep -M turns
out to be very useful:
pcregrep --buffer-size 10M -M '\bperror\b.*\n.*\bexit\b' `git ls-files`
It was confusing to have a mix of seconds and milliseconds. For all
upstream testing (eg. with SeaBIOS) we are discussing everything in
milliseconds, so use those exclusively.
Add a new test program called 'boot-benchmark'. This is similar to
'boot-analysis' but it simply boots and shuts down the appliance
several times in a row and measures how long it takes, calculating
mean and standard deviation.
When a struct containing FChar fields is defined
in generator/structs.ml, the Python code generator will generate
code referencing a dirent struct instead of the correct one
thus breaking at compile time.
This bug was left unnoticed because the dirent struct is the only
one using FChar fields. Yet it prevents any other struct
from using such fields.
Signed-off-by: Matteo Cafasso <noxdafox@gmail.com>
Look for /lib/os-release in the /usr partition and try to use it, if
present, before using lsb-release later on. This should not change the
final result of the inspection, while using the os-release detection
method also for CoreOS.
Update the phony CoreOS image to use os-release instead, uploading the
version found in the current stable version.
