cleanup: a bit better error message

cleanup: verbose in human readable size

Use normal size like we use everywhere else.

cleanup: line indent

cleanup: libdm simplier error comparation

When testing return value from snprintf
use simplier form '>=' instead of  '+1 >'.

display: add display_lvname

Add simple function to print vg/lv name.
Useful i.e. in error messages.

fsadm: avoid using -a in test

pool: delay conversion prompt

First validate as much params as possible before prompting user
about conversion to data and metadata LV.

thin: fix chunk_size conversion prompt skip

Use --force only enables prompting for dangerous operation.
User has to add --yes to skip this prompt.

lvremove: remove thin volumes on damaged pools

Support remove of thin volumes With --force --force
when thin pools is damaged.

This way it's possible to remove thin pool with
unrepairable metadata without requiring to
manually edit lvm2 metadata.

lvremove -ff vg/pool

removes all thin volumes and pool even when
thin pool cannot be activated (to accept
removal of thin volumes in kernel metadata)

raid: don't skip prompt with force

Yes is meant to be used to skip all new prompts.
(--force just adds more prompts).

raid: switch to log_warn

Use log_warn for warning message.
log_error is printed when command returns error code.

mirror: mirror_or_raid_type_requested update

mirror_or_raid_type_requested really checks for mirror type.

Convert macros mirror_or_raid_type_requested() and
snapshot_type_requested() into inline functions.

make: Fix pofile and .d file generation.

Use builddir not srcdir with make pofile.

Append 'incfile:' lines to %.d files to handle newly-missing dependencies
without 'make clean' after a file is moved or deleted.

uuid: revert uuids for mirrors and raids

Using suffixes for mirrors and raids will need more work,
before this could be enabled.

Meanwhile revert to previous behavior.

Keep suffixes for thins and caches.

cleanup: ignore vg_name in /lib

Since  vg_name inside /lib function has already been ignored mostly
except for a few debug prints - make it and official internal API
feature.

vg_name is used only in  /tools while the VG is not yet openned,
and when  lvresize/lvcreate /lib function is called with VG pointer
already being used, then vg_name becomes irrelevant (it's not been
validated anyway).

So any internal user of lvcreate_params and lvresize_params does not
need to set vg_name pointer and may leave it NULL.

uuid: add more private uuid sufixes

Use suffixes for easier detection of private volumes.

This commit makes older volume UUIDs incompatible and
it most probably needs machine reboot after upgrade.

cleanup: more lv_is_ functions

thin: do not create reserved LVs

When creating pool's metadata - create initial LV for clearing with some
generic name and after the volume is create & cleared - rename it to
reserved name '_tmeta/_cmeta'.

We should not expose  'reserved' names for public LVs.

thin: repaired LV uses _meta%d

Don't leave 'regular' LV with reserved suffix for a user.
After succefull repair use 'normal' (non-reserved) LV name
for backup of original metadata.

activation: fix typo in 'activation skip' message

libdm: fix double const for "value" in dm_report_reserved_value structure

C++ may have

man: do not mention '(i)nherited' for alloc policy in vg_attr field

VG has nothing to inherit from...

raid: Allow repair to reuse PVs from same image that suffered a PV failure

When repairing RAID LVs that have multiple PVs per image, allow
replacement images to be reallocated from the PVs that have not
failed in the image if there is sufficient space.

This allows for scenarios where a 2-way RAID1 is spread across 4 PVs,
where each image lives on two PVs but doesn't use the entire space
on any of them.  If one PV fails and there is sufficient space on the
remaining PV in the image, the image can be reallocated on just the
remaining PV.

misc: after releasing a PV segment, merge it with any adjacent free space

Previously, the seg_pvs used to track free and allocated space where left
in place after 'release_pv_segment' was called to free space from an LV.
Now, an attempt is made to combine any adjacent seg_pvs that also track
free space.  Usually, this doesn't provide much benefit, but in a case
where one command might free some space and then do an allocation, it
can make a difference.  One such case is during a repair of a RAID LV,
where one PV of a multi-PV image fails.  This new behavior is used when
the replacement image can be allocated from the remaining space of the
PV that did not fail.  (First the entire image with the failed PV is
removed.  Then the image is reallocated from the remaining PVs.)

raid/misc: Allow creation of parallel areas by LV vs segment

I've changed build_parallel_areas_from_lv to take a new parameter
that allows the caller to build parallel areas by LV vs by segment.
Previously, the function created a list of parallel areas for each
segment in the given LV.  When it came time for allocation, the
parallel areas were honored on a segment basis.  This was problematic
for RAID because any new RAID image must avoid being placed on any
PVs used by other images in the RAID.  For example, if we have a
linear LV that has half its space on one PV and half on another, we
do not want an up-convert to use either of those PVs.  It should
especially not wind up with the following, where the first portion
of one LV is paired up with the second portion of the other:
------PV1-------  ------PV2-------
[ 2of2 image_1 ]  [ 1of2 image_1 ]
[ 1of2 image_0 ]  [ 2of2 image_0 ]
----------------  ----------------
Previously, it was possible for this to happen.  The change makes
it so that the returned parallel areas list contains one "super"
segment (seg_pvs) with a list of all the PVs from every actual
segment in the given LV and covering the entire logical extent range.

This change allows RAID conversions to function properly when there
are existing images that contain multiple segments that span more
than one PV.

test:  Test addition to show incorrect allocator behavior

If a RAID LV has images that are spread across more than one PV
and you allocate a new image that requires more than one PV,
parallel_areas is only honored for one segment.  This commit
adds a test for this condition.

filters: always reevaluate filter before creating a PV

...to avoid using cached value (persistent filter) and therefore
not noticing any change made after last scan/filtering - the state
of the device may have changed, for example new signatures added.

$ lvm dumpconfig --type diff
allocation {
use_blkid_wiping=0
}
devices {
obtain_device_list_from_udev=0
}

$ cat /etc/lvm/cache/.cache | grep sda

$ vgscan
  Reading all physical volumes.  This may take a while...
  Found volume group "fedora" using metadata type lvm2

$ cat /etc/lvm/cache/.cache | grep sda
"/dev/sda",

$ parted /dev/sda mklabel gpt
Information: You may need to update /etc/fstab.

$ parted /dev/sda print
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sda: 134MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start  End  Size  File system  Name  Flags

$ cat /etc/lvm/cache/.cache | grep sda
"/dev/sda",

====

Before this patch:
$ pvcreate /dev/sda
  Physical volume "/dev/sda" successfully created

With this patch applied:
$ pvcreate /dev/sda
  Physical volume /dev/sda not found
  Device /dev/sda not found (or ignored by filtering).

coverity: mark new switch cases with 'fall through' comment for coverity to stop complaining

coverity: fix issues reported by coverity

post-release

pre-release

pre-release

man: More /dev/vg and /dev/mapper documentation.

select: add message about 'help' field to get more help on each error hit during selection parsing

Inform about 'help' to get more help about selection fields and operators
after each syntax error hit:

  "Use 'help' for selection to get more help."

select: also mark uncomparable/unselectable fields in field/selection help

select: add FLD_UNCOMPARABLE flag for fields which can't be compared

A field where it has no meaning to do any type of comparison is the
implicit "help" or "?" field. The error given was a bit cryptic
before this patch, the FLD_UNCOMPARABLE flag makes it easier to identify
this situation anywhere in the code and provide much better error message.
This flag can be applied to other fields that may appear in the future -
mostly usable for implicit fields as they always have special purpose
(so we're not exporting it in libdevmapper for now - usual reporting
fields don't need this).

Before this patch:

$ vgs -S help=1
  dm_report_object: no data assigned to field help
  dm_report_object: no data assigned to field help

(...which is true actually, but let's provide something better...)

With this patch applied:

$vgs -S help=1
  Selection field is uncomparable: help.
  Selection syntax error at 'help=1'.

$vgs -S '(name=vg && help=1) || vg_size > 1g'
  Selection field is uncomparable: help.
  Selection syntax error at 'help=1) || vg_size > 1g'.

locking: fix cluster locking

Hunk missed from last commit 78533f72d30f6e840f66e0aae89126ef139c1f2c.

locking: Introduce LCK_ACTIVATION.

Take a local file lock to prevent concurrent activation/deactivation of LVs.
Thin/cache types and an extension for cluster support are excluded for
now.

'lvchange -ay $lv' and 'lvchange -an $lv' should no longer cause trouble
if issued concurrently: the new lock should make sure they
activate/deactivate $lv one-after-the-other, instead of overlapping.

(If anyone wants to experiment with the cluster patch, please get in touch.)

pvvmove: add a few comments

lv: fix lv_is_raid

tests: add udev sync point

Missed synchronization with udev may lead to error on vgcreate,
if previous vgremove was not handled fast enough by udev.

cleanup: use simplier test

Just like all other tests - use direct LV function test

memlock: skip more entries

Add more entries for memlock skipping - since those are never
used by lvm code in critical section (suspend state).

dmsetup: no need to check for "help" field name after report init

The "help" field (as well as "?") is implicit now - libdevmapper
takes care of it completely.

pvmove: Fix code that looks up the "move pv" for display

'lvs' would segfault if trying to display the "move pv" if the
pvmove was run with '--atomic'.  The structure of an atomic pvmove
is different and requires us to descend another level in the
LV tree to retrieve the PV information.

pvmove: Clean-up iterator.

In 'find_pvmove_lv', separate the code that searches the atomic
pvmove LVs from the code that searches the normal pvmove LVs.  This
cleans up the segment iterator code a bit.

report: display explicit fields first, then implicit fields in field help

It's better to have implicit fields at the very end of the output
so users can see them without scrolling back if the list of fields
is long (the "help" is also an implicit field now so it should be
easily visible).

libdevmapper: revoke commit 7c86131233011c9fb81190bcb40d5d4ac54a533d

We have "help" and "?" defined as implicit fields now. As such, we
don't need to export these names in libdevmapper (as it was introduced
by commit 7c86131233011c9fb81190bcb40d5d4ac54a533d within this release).
If anyone uses these field names by mistake, the libdevmapper code can
error out correctly if it detects that the set of explicit field names
(the ones supplied by "fields" arg in dm_report_init/dm_report_init_with_selection)
contains any of the implicit field names (the ones defined internally
by libdevmapper itself).

report: make "help" and "?" field implicit

Making "help" and "?" implicit also simplifies code since the
dm_report_init caller (lvm/dmsetup) doesn't need to check on
dm_report_init return whether "help" or "?" was hit while parsing
fields/sort keys in libdevmapper.

The libdevmapper now sets internal "RH_ALREADY_REPORTED" flag
after it reports the "help" or "?" implicit field. Then libdevmapper
itself checks for this flag in dm_report_object and if found,
the actual reporting is skipped (because the "help" implicit field
was reported instead of the actual report).

select: add list of allowed types for each selection operator mentioned in help

pvmove: tidy

tests: remove dmeventd usage

This test is testing --use-policies on cmdline.
So monitoring must not be used.

cleanup: rename variable wait

With older system headers (sys/wait.h) this shadows declaration.

cleanup: more readable

Older gcc complained a bit about uninitialized vars
so reorder code for better readability.

lvchange: better --refresh of raid and mirrors

Use lv_check_not_in_use() to detect openned device.
Plain info.open_count is not good enough for udev random
device openning.

test: Clean-up pvmove-basic for atomic pvmove test

The way I was testing for the existence of pvmove mimages was
incorrect for rhel5.  This patch makes it more generic/universal.

man: lvmthin

Clean up inconsistencies in the last change.
Improve some bad formatting.

cleanup: use insert_layer_for_lv implicit rename

There is implicit rename for certain layered device.
Do it now for _tdata, _cdata and _corig.

TODO: use better API here...

lvconvert: print warning when not convert thinpool

Warning about destruction should not be printed,
When we are converting already existing pool
(improving original in-release commit bbf4b2c1c9d)

compilation: fix warnings: build_dm_uuid now accepts whole struct logical_volume, not lvid

replicator/replicator.c:338:2: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default]
replicator/replicator.c:629:3: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default]
replicator/replicator.c:644:6: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default]
replicator/replicator.c:668:7: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default]
replicator/replicator.c:677:4: warning: passing argument 2 of 'build_dm_uuid' from incompatible pointer type [enabled by default]

man: add man page entry for dmsetup info -c -S/--select + minor cleanups

cleanup: gcc warnings and report-select test vs snap_percent 0%

Fix gcc warnings:
libdm-report.c:1952:5: warning: "end_op_flag_hit" may be used uninitialized in this function [-Wmaybe-uninitialized]
libdm-report.c:2232:28: warning: "custom" may be used uninitialized in this function [-Wmaybe-uninitialized]

And snap_percent is not 0% in dm < 1.10.0 so
don't test comparison with 0% here.

WHATS_NEW: commit 76467bdcfd297ffbe2c088b6340ecc7d17d56742

Ordering string list items on reports is also new compared to
previous state where items were not ordered at all and they
got reported simply as they appeared/were processed.

WHATS_NEW: commits 7dbbc05a69c4cb9756464720cad29e3c1ed971c3..b16f5633ab199dedfd25f08562f686a6fb4aba9d

Report selection support...

pvmove: Enable all-or-nothing (atomic) pvmoves

pvmove can be used to move single LVs by name or multiple LVs that
lie within the specified PV range (e.g. /dev/sdb1:0-1000).  When
moving more than one LV, the portions of those LVs that are in the
range to be moved are added to a new temporary pvmove LV.  The LVs
then point to the range in the pvmove LV, rather than the PV
range.

Example 1:
We have two LVs in this example.  After they were
created, the first LV was grown, yeilding two segments
in LV1.  So, there are two LVs with a total of three
segments.

Before pvmove:
      ---------  ---------   ---------
      | LV1s0 |  | LV2s0 |   | LV1s1 |
      ---------  ---------   ---------
         |           |           |
   -------------------------------------
PV | 000 - 255 | 256 - 511 | 512 - 767 |
   -------------------------------------

After pvmove inserts the temporary pvmove LV:
          ---------   ---------   ---------
          | LV1s0 |   | LV2s0 |   | LV1s1 |
          ---------   ---------   ---------
              |           |           |
        -------------------------------------
pvmove0 |   seg 0   |   seg 1   |   seg 2   |
        -------------------------------------
              |           |           |
        -------------------------------------
PV      | 000 - 255 | 256 - 511 | 512 - 767 |
        -------------------------------------

Each of the affected LV segments now point to a
range of blocks in the pvmove LV, which purposefully
corresponds to the segments moved from the original
LVs into the temporary pvmove LV.

The current implementation goes on from here to mirror the temporary
pvmove LV by segment.  Further, as the pvmove LV is activated, only
one of its segments is actually mirrored (i.e. "moving") at a time.
The rest are either complete or not addressed yet.  If the pvmove
is aborted, those segments that are completed will remain on the
destination and those that are not yet addressed or in the process
of moving will stay on the source PV.  Thus, it is possible to have
a partially completed move - some LVs (or certain segments of LVs)
on the source PV and some on the destination.

Example 2:
What 'example 1' might look if it was half-way
through the move.
             ---------   ---------   ---------
             | LV1s0 |   | LV2s0 |   | LV1s1 |
             ---------   ---------   ---------
                 |           |           |
           -------------------------------------
pvmove0    |   seg 0   |   seg 1   |   seg 2   |
           -------------------------------------
                 |           |           |
                 |     -------------------------
source PV        |     | 256 - 511 | 512 - 767 |
                 |     -------------------------
                 |           ||
           -------------------------
dest PV    | 000 - 255 | 256 - 511 |
           -------------------------

This update allows the user to specify that they would like the
pvmove mirror created "by LV" rather than "by segment".  That is,
the pvmove LV becomes an image in an encapsulating mirror along
with the allocated copy image.

Example 3:
A pvmove that is performed "by LV" rather than "by segment".

                   ---------   ---------
                   | LV1s0 |   | LV2s0 |
                   ---------   ---------
                       |           |
                 -------------------------
        pvmove0  |  * LV-level mirror *  |
                 -------------------------
                             /                \
   pvmove_mimage0   /          pvmove_mimage1
   -------------------------   -------------------------
   |   seg 0   |   seg 1   |   |   seg 0   |   seg 1   |
   -------------------------   -------------------------
        |            |               |           |
   -------------------------   -------------------------
   | 000 - 255 | 256 - 511 |   | 000 - 255 | 256 - 511 |
   -------------------------   -------------------------
           source PV                    dest PV

The thing that differentiates a pvmove done in this way and a simple
"up-convert" from linear to mirror is the preservation of the
distinct segments.  A normal up-convert would simply allocate the
necessary space with no regard for segment boundaries.  The pvmove
operation must preserve the segments because they are the critical
boundary between the segments of the LVs being moved.  So, when the
pvmove copy image is allocated, all corresponding segments must be
allocated.  The code that merges ajoining segments that are part of
the same LV when the metadata is written must also be avoided in
this case.  This method of mirroring is unique enough to warrant its
own definitional macro, MIRROR_BY_SEGMENTED_LV.  This joins the two
existing macros: MIRROR_BY_SEG (for original pvmove) and MIRROR_BY_LV
(for user created mirrors).

The advantages of performing pvmove in this way is that all of the
LVs affected can be moved together.  It is an all-or-nothing approach
that leaves all LV segments on the source PV if the move is aborted.
Additionally, a mirror log can be used (in the future) to provide tracking
of progress; allowing the copy to continue where it left off in the event
there is a deactivation.

test: fix report_select test to work in cluster

The snapshot LV is used to check selection of percent values.
The orig volume must be activated exclusively in cluster.

tests: update lvcreate-thin for latest changes

With recent changes introduced with the report selection support,
the content of lv_modules field is of string list type (before
it was just string type).

String list elements are always ordered now so update lvcreate-thin
test to expect the elements to be ordered.

prop: update FIELD macro to accomodate the differentiation of number, size and percent field values

The differentiation of the original number field into number, size and
percent field types has been introduced with recent changes for report
selection support.

report: select: add man pages for report selection feature

report: select: add --select arg to lvm devtypes

report: add support for implicit fields, add implicit "selected" field

Implicit fields are fields that are registered with the report
and reported internally by libdevmapper itself (compared to explicit
fields that are registered by the layer above libdevmapper - e.g. LVM,
dmsetup...).

The "selected" field is the implicit field (for now the only one)
that reports the result of the selection. Since the selection itself
is the property of the libdevmapper, the upper layer using dm_report_init
can't register this field itself and it must be done directly at
libdevmapper layer.

The "selected" field is internally registered as part of the "common"
report type with id 0x80000000 (the last bit in uin32_t) which is then
reserved (the explicit report types are then checked if they do not
contain this id and if yes, we error out).

This way, the "selected" field is recognized by all libdevmapper users
that initialize the reporting with "dm_report_init_with_selection".
If reporting is initialized with the classical "dm_report_init",
there's no functional change (so the "selected" field is not defined
and it's not recognized).

tests: select: add test for report selection feature

report: select: add support for percent selection

report: select: refactor: move percent handling code to libdm for reuse

report: select: add support for reserved value recognition in report selection string - add struct dm_report_reserved_value

Make dm_report_init_with_selection to accept an argument with an
array of reserved values where each element contains a triple:

  {dm report field type, reserved value, array of strings representing this value}

When the selection is parsed, we always check whether a string
representation of some reserved value is not hit and if it is,
we use the reserved value assigned for this string instead of
trying to parse it as a value of certain field type.

This makes it possible to define selections like:

   ... --select lv_major=undefined (or -1 or unknown or undef or whatever string representations are registered for this reserved value in the future)
   ... --select lv_read_ahead=auto
   ... --select vg_mda_copies=unmanaged

With this, each time the field value of certain type is hit
and when we compare it with the selection, we use the proper
value for comparison.

For now, register these reserved values that are used at the moment
(also more descriptive names are used for the values):

  const uint64_t _reserved_number_undef_64 = UINT64_MAX;
  const uint64_t _reserved_number_unmanaged_64 = UINT64_MAX - 1;
  const uint64_t _reserved_size_auto_64 = UINT64_MAX;

 {
  {DM_REPORT_FIELD_TYPE_NUMBER, _reserved_number_undef_64, {"-1", "undefined", "undef", "unknown", NULL}},
  {DM_REPORT_FIELD_TYPE_NUMBER, _reserved_number_unmanaged_64, {"unmanaged", NULL}},
  {DM_REPORT_FIELD_TYPE_SIZE, _reserved_size_auto_64, {"auto", NULL}},
  NULL
 }

Same reserved value of different field types do not collide.
All arrays are null-terminated.

The list of reserved values is automatically displayed within
selection help output:

  Selection operands
  ------------------
  ...

  Reserved values
  ---------------
    -1, undefined, undef, unknown   - Reserved value for undefined numeric value. [number]
    unmanaged                       - Reserved value for unmanaged number of metadata copies in VG. [number]
    auto                            - Reserved value for size that is automatically calculated. [size]

  Selection operators
  -------------------
  ...

report: select: show field type in field list if in context of selection

When the field list is displayed as help for constructing selection
criteria, show also the field value type. This is useful for users
to know what set of operators are allowed for the type - the subsequent
"Selection operands" section in the help output summarize all known
types that can be used in selection.

report: select: add help for creating selections

The "<lvm command> -S/--select help" shows help (including list of fields to match against):

  ...field list here including the field type name...

  Selection operands
  ------------------
    field               - Reporting field.
    number              - Non-negative integer value.
    size                - Floating point value with units specified.
    string              - Characters quoted by ' or " or unquoted.
    string list         - Strings enclosed by [ ] and elements delimited by either
                          "all items must match" or "at least one item must match" operator.
    regular expression  - Characters quoted by ' or " or unquoted.

  Selection operators
  -------------------
    Comparison operators:
        =~  - Matching regular expression.
        !~  - Not matching regular expression.
         =  - Equal to.
        !=  - Not equal to.
        >=  - Greater than or equal to.
         >  - Greater than
        <=  - Less than or equal to.
         <  - Less than.

    Logical and grouping operators:
        &&  - All fields must match
         ,  - All fields must match
        ||  - At least one field must match
         #  - At least one field must match
         !  - Logical negation
         (  - Left parenthesis
         )  - Right parenthesis
         [  - List start
         ]  - List end

report: select: add support for comparing string lists with selection defined

report: select: add support for processing string lists in selection

Selection list items are enclosed in '[' and ']' (if there's only
one item, the '[' and ']' can be omitted). Each element of the list
is a string (either quoted or unquoted, like the usual string operand
used in selection) and each element is delimited either by conjunction
(meaining "match all") or disjunction operator (meaning "match any").

For example, if "," is the conjuction operator and "/" is the
disjunction operator then:

  lv_tags=[a,b,c]

...will match all fields where tags contain *all* a, b and c.

  lv_tags=[a/b/c]

...will match all fields where tags contain *any* of a, b, or c.

Mixing operators within the list is not supported:

  lv_tags=[a,b/c]

...will give an error.

The order in which items are defined in the selection do not matter.

This patch enhances the selection parsing functionality to recognize
such lists.

report: select: add DM_REPORT_FIELD_TYPE_STRING_LIST to make a difference between STRING and STRING_LIST

The {pv,vg,lv,seg}_tags and lv_modules fields are reported as string
lists using the new dm_report_field_string_list - so we just pass
the list to the fn that takes care of reporting and item sorting itself.

report: select: add dm_report_field_string_list to libdm

Add a separate dm_report_field_string_list fn to libdevmapper to
support reporting string lists. Before, the code used libdevmappers's
dm_report_field_string fn which required formatting the list to a
single string. This functionality is now moved to libdevmapper
and the code that needs to report the string list just needs
to pass the list itself and libdevmapper will take care of this.
This also enhances code reuse.

The dm_report_field_string_list also accepts an argument to define
custom delimiter to use. If not defined, a default "," (comma) is
used as item delimiter in the string list reported.

The dm_report_field_string_list automatically sorts the items in
the list before formatting it to a final string. It also encodes
the position and length within the final string where each element
can be found. This can be used to support checking against each
list item reported since since when formatted as a single string
for the actual report, we would lose this information otherwise
(we don't want to copy each item, the position and length within
the final string is enough for us to get the original items back).

When such lists are checked against the selection tree, we can check
each item individually this way and we can support operators like
"match any" and "match all".

report: select: refactor: move str_list to libdm

The list of strings is used quite frequently and we'd like to reuse
this simple structure for report selection support too. Make it part
of libdevmapper for general reuse throughout the code.

This also simplifies the LVM code a bit since we don't need to
include and manage lvm-types.h anymore (the string list was the
only structure defined there).

report: select: add --select arg to pvdisplay, vgdisplay and lvdisplay

report: select: add --select arg to pvs, vgs and lvs

report: select: add --select arg to dmsetup

report: select: use _check_report_selection in dm_report_object to report only objects that satisfy the report selection

This is rebased and edited version of the original design and
patch proposed by Jun'ichi Nomura:
  http://www.redhat.com/archives/dm-devel/2007-April/msg00025.html

This activates the actual selection process in dm_report_object.

report: select: add _check_selection fn to support checking fields against given selections

This is rebased and edited versions of the original design and
patch proposed by Jun'ichi Nomura:
  http://www.redhat.com/archives/dm-devel/2007-April/msg00025.html

The _check_selection implements the actual field checking against the
selection tree.

report: select: add dm_report_init_with_selection to libdm

This is rebased and edited version of the original design and
patch proposed by Jun'ichi Nomura:
  http://www.redhat.com/archives/dm-devel/2007-April/msg00025.html

The dm_report_init_with_selection is the same as dm_report_init
but it contains an additional argument to set the selection
in the form of a string that contains field names to check against and
selection operators. The selection string is parsend and a selection
tree is composed for use in the checks against individual fields when
the report is processed. The parsed selection tree is stored in dm_report
structure as "selection_root".

report: select: add supporting infrastucture for token parsing in report selections

This is rebased and edited version of the original design and
patch proposed by Jun'ichi Nomura:
  http://www.redhat.com/archives/dm-devel/2007-April/msg00025.html

Add support for parsing numbers, strings (quoted or unquoted), regexes
and operators amogst these operands in selection condition supplied.

report: select: add structs for report selection

This is rebased and edited version of the original design and
patch proposed by Jun'ichi Nomura:
  http://www.redhat.com/archives/dm-devel/2007-April/msg00025.html

This patch defines operators and structures that will be used
to store the report selection against which the actual values
reported will be checked.

  Selection operators
  -------------------
    Comparison operators:
        =~  - Matching regular expression.
        !~  - Not matching regular expression.
         =  - Equal to.
        !=  - Not equal to.
        >=  - Greater than or equal to.
         >  - Greater than
        <=  - Less than or equal to.
         <  - Less than.

    Logical and grouping operators:
        &&  - All fields must match
         ,  - All fields must match
        ||  - At least one field must match
         #  - At least one field must match
         !  - Logical negation
         (  - Left parenthesis
         )  - Right parenthesis

report: select: add DM_REPORT_FIELD_TYPE_SIZE to make a difference between NUMBER and SIZE

This makes it easier to check against the fields (following patches for
report selection) and check whether size units are allowed or not
with the field value.

tests: check new snapshot skills

tests: detect version of thin_restore command

Skip test when missing.

tests: wait for udev

Before test exits, wait for udev.

cleanup: we already know max device name size

Use NAME_LEN constant to simplify creation of device name.
Since the max size should be already tested in validation,
throw INTERNAL_ERROR if the size of vg/lv is bigger then NAME_LEN.

cleanup: use stack for small buffer

Avoid error checking of allocation error when just few bytes are needed
for short string and use stack.
Stacktrace lvmetad_pv_gone() fail path.

snapshot: %ORIGIN is relative to data size

Let's use the size of origin as the real base for percenta calculation,
and 'silenly' add needed metadata space for snapshot.

So now command   'lvcreate -s -l100%ORIGIN vg/lv' should always create a
snapshot to handle full device overwrite.

snapshot: report proper error message

Expresing -lXX%LV is not valid for snapshot, but error message for
snapshost case was not complete and missed %ORIGIN.
Also document correct settings for in manpage properly where
it missed %PVS.

snapshot: do not spawn when origin is not active

Since the code is not doing anything when origin is not active,
avoid spawning polling thread.

snapshot: check snapshot exists

Return 0 if the LV is not even snapshot.