| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This file is already hard-linked into the current directory, so
the relative path is not required.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current groups are defined very conservatively using the
following criteria:
(a) Would be impossible to implement on Windows because of
sheer architectural differences (eg: mknod).
(b) Already optional (augeas, inotify).
(c) Not currently optional but not implemented on older RHEL and
Debian releases (ntfs-3g.probe, scrub, zerofree).
The optional groups I've defined according to these criteria are:
. augeas
. inotify
. linuxfsuuid
. linuxmodules
. linuxxattrs
. lvm2
. mknod
. ntfs3g
. scrub
. selinux
. zerofree
(Note that these choices don't prevent us from adding more
optional groups in future. On the other hand to avoid breaking
ABIs we would not wish to change the above groups).
The rest of this large commit is really just implementation:
Each optional function is classified using Optional "group"
flag in the generator.
The daemon has to implement a function
int optgroup_<name>_available (void);
for each optional group. Some of these functions are fixed at
compile time, and some do simple run-time tests.
The do_available implementation in the daemon looks up the correct
function in a table and runs it.
We document the optional groups in the guestfs(3) man page.
Also: I added a NOT_AVAILABLE macro in order to unify all the
existing places where we had a message equivalent to
"function __func__ is not available".
|
|
|
Start a new API allowing groups of functions to be tested for
availability.
There are two reasons for this:
(1) If libguestfs is built with missing dependencies (eg. no Augeas lib)
then the corresponding functions are disabled in the appliance. Up till
now there has been no way to test for this except to speculatively
issue commands and check for errors.
(2) When we port the daemon to Win32 it is likely that major pieces of
functionality won't be available (eg. LVM support). This API gives
a way to test for that.
There is no change for existing clients: you still have to check for
errors from individual API calls.
For new clients, you will be able to test for availability of particular
APIs.
Usage scenario (A): An LVM editing tool which requires
both the LVM API and inotify in order to function at all:
char *apis[] = { "inotify", "lvm2", NULL };
r = guestfs_available (g, apis);
if (r == -1) {
/* print an error and exit */
}
Usage scenario (B): A general purpose tool which optionally provides
configuration file editing, but this can be disabled, the result
merely being reduced functionality:
char *apis[] = { "augeas", NULL };
r = guestfs_available (g, apis);
enable_config_edit_menus = r == 0;
|
