Peter Rajnoha [Fri, 28 Nov 2014 14:04:25 +0000 (15:04 +0100)]
toollib: initialize handles (including reporting for selection) for _select_match_* used in process_each_* fns
Call _init_processing_handle, _init_selection_handle and
_destroy_processing_handle in process_each_* and related functions to
set up and destroy handles used while processing items.
Peter Rajnoha [Fri, 28 Nov 2014 13:46:18 +0000 (14:46 +0100)]
toollib: add init_processing_handle, init_selection_handle and destroy_processing_handle helper functions
The init_processing_handle, init_selection_handle and
destroy_processing_handle are helper functions that allocate and
initialize the handles used when processing items in process_each_*
and related functions.
Peter Rajnoha [Fri, 28 Nov 2014 13:34:56 +0000 (14:34 +0100)]
toollib: pass struct processing_handle to _select_match_* functions
The "struct processing_handle" contains handles to drive the selection/matching
so pass it to the _select_match_* functions which are entry points to the
selection mechanism used in process_each_* and related functions.
This is revised and edited version of former Dave Teigland's patch which
provided starting point for all the select support in process_each_* fns.
Peter Rajnoha [Tue, 2 Dec 2014 12:14:12 +0000 (13:14 +0100)]
report: add report_init_for_selection fn and modify report_object to support reporting for selection only
The new "report_init_for_selection" is just a wrapper over
dm_report_init_with_selection that initializes reporting for selection
only. This means we're not going to do the actual reporting to output
for display and as such we intialize reporting as if no fields are reported
or sorted. The only fields "reported" are taken from the selection criteria
string and all such fields are marked as hidden automatically (FLD_HIDDEN flag).
These fields are used solely for selection criteria matching.
Also, modify existing report_object function that was used for reporting to
output for display. Now, it can either cause reporting to output or reporting
for selection only. The selection result is stored in struct selection_handle's
"selected" variable which can be handled further by any report_object caller.
Peter Rajnoha [Thu, 27 Nov 2014 14:02:13 +0000 (15:02 +0100)]
toollib: replace void *handle with struct processing_handle for use in processing functions (process_each_*/process_single_* and related)
This patch replaces "void *handle" with "struct processing_handle *handle"
in process_each_*, process_single_* and related functions.
The struct processing_handle consists of two handles inside now:
- the "struct selection_handle *selection_handle" used for
applying selection criteria while processing process_each_*,
process_single_* and related functions (patches using this
logic will follow)
- the "void* custom_handle" (this is actually the original handle
used before this patch - a pointer to custom data passed into
process_each_*, process_single_* and related functions).
Peter Rajnoha [Mon, 24 Nov 2014 10:07:39 +0000 (11:07 +0100)]
libdm: report: add dm_report_object_is_selected
The new dm_report_object_is_selected fn makes it possible to opt whether the
object reported should be displayed on output or not. Also, in addition to
that, it makes it possible to save the result of selection (either 0 or 1).
So dm_report_object_is_selected is simply more general form of object
reporting fn - combinations now allow for:
dm_report_object_is_selected(rh, object, 1, NULL):
This is exactly the original dm_report_object fn and it's fully equal
to it.
dm_report_object_is_selected(rh, object, 0, selected):
Do not display the result on output, but save info whether the object
is selected or not in 'selected' variable.
dm_report_object_is_selected(rh, object, 1, selected):
Display the result on output (if it passes selection criteria) and save
whether the object is selected or not in 'selected' variable.
dm_report_object(rh, object, 0, NULL):
This combination is not allowed - it will end up with internal error.
We're either interested in selection status or we want to display the
result on output or both, but never nothing of the two.
Peter Rajnoha [Mon, 9 Feb 2015 13:16:24 +0000 (14:16 +0100)]
lvm: recognize LVM_COMMAND_PROFILE env var for default command profile to use in LVM commands
Once LVM_COMMAND_PROFILE environment variable is specified, the profile
referenced is used just like it was specified using "<lvm command> --commandprofile".
If both --commandprofile cmd line option and LVM_COMMAND_PROFILE env
var is used, the --commandprofile cmd line option gets preference.
Petr Rockai [Thu, 26 Jun 2014 23:25:18 +0000 (01:25 +0200)]
NIX: Refactor around the new test runner.
- The RPM build and the tests are now executed in separate VMs.
- Run the testsuite by using the new lvm2-testsuite RPM.
- The VM running the tests is restarted from the outside if it hangs, and the
runner keeps a journal to avoid running a bad test ad infinitum.
- TODO: lcov reports and more intelligent VM rebooting (track the journal)