mirror of
git://sourceware.org/git/lvm2.git
synced 2024-12-22 17:35:59 +03:00
LVM2 mirror repository
https://sourceware.org/lvm2/
d1a149b51d
. Define a prototype for every lvm command. . Verify every user command matches one. . Generate help text and man pages from them. The new file command-lines.in defines a prototype for every unique lvm command. A unique lvm command is a unique combination of: command name + required option args + required positional args. Each of these prototypes also includes the optional option args and optional positional args that the command will accept, a description, and a unique string ID for the definition. Any valid command will match one of the prototypes. Here's an example of the lvresize command definitions from command-lines.in, there are three unique lvresize commands: lvresize --size SizeMB LV OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --test, --poolmetadatasize SizeMB OP: PV ... ID: lvresize_by_size DESC: Resize an LV by a specified size. lvresize LV PV ... OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --resizefs, --stripes Number, --stripesize SizeKB, --test ID: lvresize_by_pv DESC: Resize an LV by a specified PV. lvresize --poolmetadatasize SizeMB LV_thinpool OO: --alloc Alloc, --autobackup Bool, --force, --nofsck, --nosync, --noudevsync, --reportformat String, --stripes Number, --stripesize SizeKB, --test OP: PV ... ID: lvresize_pool_metadata_by_size DESC: Resize the metadata SubLV of a pool LV. The three commands have separate definitions because they have different required parameters. Required parameters are specified on the first line of the definition. Optional options are listed after OO, and optional positional args are listed after OP. This data is used to generate corresponding command definition structures for lvm in command-lines.h. "usage" text is also generated, so it is always in sync with the definitions. Example of the corresponding generated structure in command-lines.h for the first lvresize prototype (these structures are never edited directly): commands[78].name = "lvresize"; commands[78].command_line_id = "lvresize_by_size"; commands[78].command_line_enum = lvresize_by_size_CMD; commands[78].fn = lvresize; commands[78].ro_count = 1; commands[78].rp_count = 1; commands[78].oo_count = 22; commands[78].op_count = 1; commands[78].desc = "DESC: Resize an LV by a specified size."; commands[78].usage = "lvresize --size Number[m|unit] LV" " [ --alloc contiguous|cling|normal|anywhere|inherit, --autobackup y|n, --nofsck, --nosync, --reportformat String, --resizefs, --stripes Number, --stripesize Number[k|unit], --poolmetadatasize Number[m|unit] ]" " [ PV ... ]"; commands[78].usage_common = " [ --commandprofile String, --config String, --debug, --driverloaded y|n, --help, --profile String, --quiet, --verbose, --version, --yes, --force, --test, --noudevsync ]"; commands[78].required_opt_args[0].opt = size_ARG; commands[78].required_opt_args[0].def.val_bits = val_enum_to_bit(sizemb_VAL); commands[78].required_pos_args[0].pos = 1; commands[78].required_pos_args[0].def.val_bits = val_enum_to_bit(lv_VAL); commands[78].optional_opt_args[0].opt = commandprofile_ARG; commands[78].optional_opt_args[0].def.val_bits = val_enum_to_bit(string_VAL); commands[78].optional_opt_args[1].opt = config_ARG; commands[78].optional_opt_args[1].def.val_bits = val_enum_to_bit(string_VAL); commands[78].optional_opt_args[2].opt = debug_ARG; commands[78].optional_opt_args[3].opt = driverloaded_ARG; commands[78].optional_opt_args[3].def.val_bits = val_enum_to_bit(bool_VAL); commands[78].optional_opt_args[4].opt = help_ARG; commands[78].optional_opt_args[5].opt = profile_ARG; commands[78].optional_opt_args[5].def.val_bits = val_enum_to_bit(string_VAL); commands[78].optional_opt_args[6].opt = quiet_ARG; commands[78].optional_opt_args[7].opt = verbose_ARG; commands[78].optional_opt_args[8].opt = version_ARG; commands[78].optional_opt_args[9].opt = yes_ARG; commands[78].optional_opt_args[10].opt = alloc_ARG; commands[78].optional_opt_args[10].def.val_bits = val_enum_to_bit(alloc_VAL); commands[78].optional_opt_args[11].opt = autobackup_ARG; commands[78].optional_opt_args[11].def.val_bits = val_enum_to_bit(bool_VAL); commands[78].optional_opt_args[12].opt = force_ARG; commands[78].optional_opt_args[13].opt = nofsck_ARG; commands[78].optional_opt_args[14].opt = nosync_ARG; commands[78].optional_opt_args[15].opt = noudevsync_ARG; commands[78].optional_opt_args[16].opt = reportformat_ARG; commands[78].optional_opt_args[16].def.val_bits = val_enum_to_bit(string_VAL); commands[78].optional_opt_args[17].opt = resizefs_ARG; commands[78].optional_opt_args[18].opt = stripes_ARG; commands[78].optional_opt_args[18].def.val_bits = val_enum_to_bit(number_VAL); commands[78].optional_opt_args[19].opt = stripesize_ARG; commands[78].optional_opt_args[19].def.val_bits = val_enum_to_bit(sizekb_VAL); commands[78].optional_opt_args[20].opt = test_ARG; commands[78].optional_opt_args[21].opt = poolmetadatasize_ARG; commands[78].optional_opt_args[21].def.val_bits = val_enum_to_bit(sizemb_VAL); commands[78].optional_pos_args[0].pos = 2; commands[78].optional_pos_args[0].def.val_bits = val_enum_to_bit(pv_VAL); commands[78].optional_pos_args[0].def.flags = ARG_DEF_FLAG_MAY_REPEAT; Every user-entered command is compared against the set of command structures, and matched with one. An error is reported if an entered command does not have the required parameters for any definition. The closest match is printed as a suggestion, and running lvresize --help will display the usage for each possible lvresize command, e.g.: $ lvresize --help lvresize - Resize a logical volume Resize an LV by a specified size. lvresize --size Number[m|unit] LV [ --alloc contiguous|cling|normal|anywhere|inherit, --autobackup y|n, --nofsck, --nosync, --reportformat String, --resizefs, --stripes Number, --stripesize Number[k|unit], --poolmetadatasize Number[m|unit] ] [ PV ... ] Resize an LV by a specified PV. lvresize LV PV ... [ --alloc contiguous|cling|normal|anywhere|inherit, --autobackup y|n, --nofsck, --nosync, --reportformat String, --resizefs, --stripes Number, --stripesize Number[k|unit] ] Resize the metadata SubLV of a pool LV. lvresize --poolmetadatasize Number[m|unit] LV_thinpool [ --alloc contiguous|cling|normal|anywhere|inherit, --autobackup y|n, --nofsck, --nosync, --reportformat String, --stripes Number, --stripesize Number[k|unit] ] [ PV ... ] Common options: [ --commandprofile String, --config String, --debug, --driverloaded y|n, --help, --profile String, --quiet, --verbose, --version, --yes, --force, --test, --noudevsync ] (Use --help --help for usage notes.) $ lvresize --poolmetadatasize 4 Failed to find a matching command definition. Closest command usage is: lvresize --poolmetadatasize Number[m|unit] LV_thinpool Man page prototypes are also generated from the same original command definitions, and are always in sync with the code and help text. Very early in command execution, a matching command definition is found. lvm then knows the operation being done, and that the provided args conform to the definition. This will allow lots of ad hoc checking/validation to be removed throughout the code. Each command definition can also be routed to a specific function to implement it. The function is associated with an enum value for the command definition (generated from the ID string.) These per-command-definition implementation functions have not yet been created, so all commands currently fall back to the existing implementation. Using per-command-definition functions will allow lots of code to be removed which tries to figure out what the command is meant to do. This is currently based on ad hoc and complicated option analysis. When using the new functions, what the command is doing is already known from the associated command definition. So, this first phase validates every user-entered command against the set of command prototypes, then calls the existing implementation. The second phase can associate an implementation function with each definition, and take further advantage of the known operation to avoid the complicated option analysis. |
||
---|---|---|
autoconf | ||
conf | ||
coverity | ||
daemons | ||
doc | ||
include | ||
lib | ||
libdaemon | ||
libdm | ||
liblvm | ||
man | ||
nix | ||
old-tests | ||
po | ||
python | ||
report-generators | ||
reports | ||
scripts | ||
spec | ||
test | ||
tools | ||
udev | ||
unit-tests | ||
.gitignore | ||
acinclude.m4 | ||
aclocal.m4 | ||
configure | ||
configure.in | ||
COPYING | ||
COPYING.LIB | ||
INSTALL | ||
make.tmpl.in | ||
Makefile.in | ||
README | ||
VERSION | ||
VERSION_DM | ||
WHATS_NEW | ||
WHATS_NEW_DM |
This tree contains the LVM2 and device-mapper tools and libraries. For more information about LVM2 read the changelog in the WHATS_NEW file. Installation instructions are in INSTALL. There is no warranty - see COPYING and COPYING.LIB. Tarballs are available from: ftp://sources.redhat.com/pub/lvm2/ The source code is stored in git: http://git.fedorahosted.org/git/lvm2.git git clone git://git.fedorahosted.org/git/lvm2.git Mailing list for general discussion related to LVM2: linux-lvm@redhat.com Subscribe from https://www.redhat.com/mailman/listinfo/linux-lvm Mailing lists for LVM2 development, patches and commits: lvm-devel@redhat.com Subscribe from https://www.redhat.com/mailman/listinfo/lvm-devel lvm2-commits@lists.fedorahosted.org (Read-only archive of commits) Subscribe from https://fedorahosted.org/mailman/listinfo/lvm2-commits Mailing list for device-mapper development, including kernel patches and multipath-tools: dm-devel@redhat.com Subscribe from https://www.redhat.com/mailman/listinfo/dm-devel The source code repository used until 7th June 2012 is accessible here: http://sources.redhat.com/cgi-bin/cvsweb.cgi/LVM2/?cvsroot=lvm2.