This large, but mainly mechanical commit, renames "attach method"
everywhere to "backend".
Backwards compatibility of the API (guestfs_{set,get}_attach_method)
and environment (LIBGUESTFS_ATTACH_METHOD) is maintained, but in new
code use guestfs_{set,get}_backend and LIBGUESTFS_BACKEND instead.
The default backend (launching qemu directly) is now called 'direct'
instead of 'appliance', although you can still use 'appliance' as a
synonym.
This creates an abstract layer below the protocol code which handles
the socket operations. This will make it easier to introduce libvirt
virSocketPtr operations in future.
In the handle, g->conn contains the connection to the appliance.
g->conn is NULL when we're not connected.
poll(2) is used instead of select(2).
All error messages about launch failing or the appliance unexpectedly
dying are handled by two common error message functions, and these
contain a better explanation of what to do.
The second parameter passed into getline(3) is the size of the
allocated buffer, *NOT* the length of the returned line. This can be
confusing, so rename this parameter as 'allocsize' consistently
throughout the code.
This is just code motion.
Rename guestfs_safe_malloc et al to guestfs___safe_malloc etc.
To use the private functions, code now has to define
-DGUESTFS_PRIVATE_FUNCTIONS=1. This will make it easier for us in
future to work out which programs are using these functions and to
minimize both the number of programs and the functions they are
calling.
Note that the Perl, Python, OCaml, Ruby and Java bindings use
guestfs_safe_* calls. None of the other bindings do. This is a bug
(in the bindings using those functions): these functions will call the
out of memory callback on failure. This function defaults to abort(),
and since this happens from a language binding, there is no way to
change this default.
These configure flags enable code profiling (with gprof) and code
coverage (with gcov) respectively.
Although this is a nice idea, it's not currently very useful.
Libtool mangles filenames in such a way that gcov cannot locate its
datafiles.
Profiling is of dubious utility with libguestfs which is not CPU-bound
and relies extensively on running external programs (oprofile-like
system profiling that took into account libguestfs + qemu or
libguestfs + qemu + the appliance + filesystem tools *would* be
useful).
Also neither flag will help in capturing data from the appliance.
This commit models libvirt authentication events through the API,
adding one new event (GUESTFS_EVENT_LIBVIRT_AUTH) and several new
APIs:
guestfs_set_libvirt_supported_credentials
guestfs_get_libvirt_requested_credentials
guestfs_get_libvirt_requested_credential_prompt
guestfs_get_libvirt_requested_credential_challenge
guestfs_get_libvirt_requested_credential_defresult
guestfs_set_libvirt_requested_credential
See the documentation and example which shows how to use the new API.
This commit also changes existing calls to virConnectOpen* within the
library so that the new API is used.
Also included is an example (but not a test, because it's hard to see
how to automatically test the libvirt API).
Don't assume that if guestfs_case_sensitive_path returns NULL, that it
means the file does not exist.
The (previously undefined) behaviour of case_sensitive_path was that a
NULL return meant "either the file doesn't exist or some other error".
However in commit 973581780d this was
changed so that if the last element of the path didn't exist, it was
assumed to be a new file and the (non-NULL) path of the new file is
returned.
This change breaks code (including in libguestfs) which tries to use
case_sensitive_path as a dual-purpose call to fix-up a path for
Windows and test if the file exists. Such code should be rewritten so
that it explicitly tests for file existence after calling
case_sensitive_path.
I examined all the calls to case_sensitive_path in libguestfs and
modified them where necessary.
