2001-09-21 16:37:43 +04:00
#
2004-03-30 23:35:44 +04:00
# Copyright (C) 2001-2004 Sistina Software, Inc. All rights reserved.
2012-02-28 22:35:04 +04:00
# Copyright (C) 2004-2012 Red Hat, Inc. All rights reserved.
2001-09-21 16:37:43 +04:00
#
2007-09-21 14:16:45 +04:00
# This file is part of LVM2.
2001-09-21 16:37:43 +04:00
#
2004-03-30 23:35:44 +04:00
# This copyrighted material is made available to anyone wishing to use,
# modify, copy, or redistribute it subject to the terms and conditions
# of the GNU General Public License v.2.
2001-09-21 16:37:43 +04:00
#
2004-03-30 23:35:44 +04:00
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software Foundation,
2016-01-21 13:49:46 +03:00
# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
2001-09-21 16:37:43 +04:00
srcdir = @srcdir@
top_srcdir = @top_srcdir@
2009-10-02 23:10:31 +04:00
top_builddir = @top_builddir@
2001-09-21 16:37:43 +04:00
2004-04-06 19:14:23 +04:00
SOURCES = \
2017-02-10 20:36:11 +03:00
command.c \
2003-10-16 00:17:19 +04:00
dumpconfig.c \
2004-09-14 20:42:46 +04:00
formats.c \
2001-10-30 17:32:48 +03:00
lvchange.c \
2005-06-06 21:12:08 +04:00
lvconvert.c \
2015-03-12 18:23:19 +03:00
lvconvert_poll.c \
2001-11-06 22:02:26 +03:00
lvcreate.c \
2001-11-08 19:15:58 +03:00
lvdisplay.c \
2001-11-10 01:01:04 +03:00
lvextend.c \
2004-03-26 16:21:12 +03:00
lvmcmdline.c \
device usage based on devices file
The LVM devices file lists devices that lvm can use. The default
file is /etc/lvm/devices/system.devices, and the lvmdevices(8)
command is used to add or remove device entries. If the file
does not exist, or if lvm.conf includes use_devicesfile=0, then
lvm will not use a devices file. When the devices file is in use,
the regex filter is not used, and the filter settings in lvm.conf
or on the command line are ignored.
LVM records devices in the devices file using hardware-specific
IDs, such as the WWID, and attempts to use subsystem-specific
IDs for virtual device types. These device IDs are also written
in the VG metadata. When no hardware or virtual ID is available,
lvm falls back using the unstable device name as the device ID.
When devnames are used, lvm performs extra scanning to find
devices if their devname changes, e.g. after reboot.
When proper device IDs are used, an lvm command will not look
at devices outside the devices file, but when devnames are used
as a fallback, lvm will scan devices outside the devices file
to locate PVs on renamed devices. A config setting
search_for_devnames can be used to control the scanning for
renamed devname entries.
Related to the devices file, the new command option
--devices <devnames> allows a list of devices to be specified for
the command to use, overriding the devices file. The listed
devices act as a sort of devices file in terms of limiting which
devices lvm will see and use. Devices that are not listed will
appear to be missing to the lvm command.
Multiple devices files can be kept in /etc/lvm/devices, which
allows lvm to be used with different sets of devices, e.g.
system devices do not need to be exposed to a specific application,
and the application can use lvm on its own set of devices that are
not exposed to the system. The option --devicesfile <filename> is
used to select the devices file to use with the command. Without
the option set, the default system devices file is used.
Setting --devicesfile "" causes lvm to not use a devices file.
An existing, empty devices file means lvm will see no devices.
The new command vgimportdevices adds PVs from a VG to the devices
file and updates the VG metadata to include the device IDs.
vgimportdevices -a will import all VGs into the system devices file.
LVM commands run by dmeventd not use a devices file by default,
and will look at all devices on the system. A devices file can
be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If
this file exists, lvm commands run by dmeventd will use it.
Internal implementaion:
- device_ids_read - read the devices file
. add struct dev_use (du) to cmd->use_devices for each devices file entry
- dev_cache_scan - get /dev entries
. add struct device (dev) to dev_cache for each device on the system
- device_ids_match - match devices file entries to /dev entries
. match each du on cmd->use_devices to a dev in dev_cache, using device ID
. on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID
- label_scan - read lvm headers and metadata from devices
. filters are applied, those that do not need data from the device
. filter-deviceid skips devs without MATCHED_USE_ID, i.e.
skips /dev entries that are not listed in the devices file
. read lvm label from dev
. filters are applied, those that use data from the device
. read lvm metadata from dev
. add info/vginfo structs for PVs/VGs (info is "lvmcache")
- device_ids_find_renamed_devs - handle devices with unstable devname ID
where devname changed
. this step only needed when devs do not have proper device IDs,
and their dev names change, e.g. after reboot sdb becomes sdc.
. detect incorrect match because PVID in the devices file entry
does not match the PVID found when the device was read above
. undo incorrect match between du and dev above
. search system devices for new location of PVID
. update devices file with new devnames for PVIDs on renamed devices
. label_scan the renamed devs
- continue with command processing
2020-06-23 21:25:41 +03:00
lvmdevices.c \
2002-02-05 17:31:57 +03:00
lvmdiskscan.c \
2018-12-14 23:50:09 +03:00
lvpoll.c \
2001-11-08 19:15:58 +03:00
lvreduce.c \
2001-10-29 16:52:23 +03:00
lvremove.c \
2001-11-15 20:27:45 +03:00
lvrename.c \
2001-11-13 17:17:50 +03:00
lvresize.c \
2001-10-29 21:23:35 +03:00
lvscan.c \
2004-05-05 21:56:20 +04:00
polldaemon.c \
2001-10-17 19:29:31 +04:00
pvchange.c \
2007-03-31 01:00:26 +04:00
pvck.c \
2001-10-12 14:32:06 +04:00
pvcreate.c \
2001-10-18 20:55:19 +04:00
pvdisplay.c \
2003-04-30 19:28:17 +04:00
pvmove.c \
2015-03-12 18:21:43 +03:00
pvmove_poll.c \
2002-11-18 17:04:08 +03:00
pvremove.c \
2005-10-31 05:37:29 +03:00
pvresize.c \
2001-10-16 22:07:54 +04:00
pvscan.c \
2004-03-26 15:25:15 +03:00
reporter.c \
2004-09-14 20:42:46 +04:00
segtypes.c \
2014-01-30 17:09:15 +04:00
tags.c \
2001-10-12 14:32:06 +04:00
toollib.c \
2001-12-20 19:05:14 +03:00
vgcfgbackup.c \
2002-01-15 20:37:23 +03:00
vgcfgrestore.c \
2001-10-16 20:25:28 +04:00
vgchange.c \
2001-12-20 19:05:14 +03:00
vgck.c \
2001-10-12 16:21:43 +04:00
vgcreate.c \
2001-11-19 18:20:50 +03:00
vgdisplay.c \
2002-01-29 20:23:33 +03:00
vgexport.c \
2001-10-16 02:04:27 +04:00
vgextend.c \
2002-01-29 22:19:37 +03:00
vgimport.c \
2018-12-14 23:50:09 +03:00
vgimportclone.c \
device usage based on devices file
The LVM devices file lists devices that lvm can use. The default
file is /etc/lvm/devices/system.devices, and the lvmdevices(8)
command is used to add or remove device entries. If the file
does not exist, or if lvm.conf includes use_devicesfile=0, then
lvm will not use a devices file. When the devices file is in use,
the regex filter is not used, and the filter settings in lvm.conf
or on the command line are ignored.
LVM records devices in the devices file using hardware-specific
IDs, such as the WWID, and attempts to use subsystem-specific
IDs for virtual device types. These device IDs are also written
in the VG metadata. When no hardware or virtual ID is available,
lvm falls back using the unstable device name as the device ID.
When devnames are used, lvm performs extra scanning to find
devices if their devname changes, e.g. after reboot.
When proper device IDs are used, an lvm command will not look
at devices outside the devices file, but when devnames are used
as a fallback, lvm will scan devices outside the devices file
to locate PVs on renamed devices. A config setting
search_for_devnames can be used to control the scanning for
renamed devname entries.
Related to the devices file, the new command option
--devices <devnames> allows a list of devices to be specified for
the command to use, overriding the devices file. The listed
devices act as a sort of devices file in terms of limiting which
devices lvm will see and use. Devices that are not listed will
appear to be missing to the lvm command.
Multiple devices files can be kept in /etc/lvm/devices, which
allows lvm to be used with different sets of devices, e.g.
system devices do not need to be exposed to a specific application,
and the application can use lvm on its own set of devices that are
not exposed to the system. The option --devicesfile <filename> is
used to select the devices file to use with the command. Without
the option set, the default system devices file is used.
Setting --devicesfile "" causes lvm to not use a devices file.
An existing, empty devices file means lvm will see no devices.
The new command vgimportdevices adds PVs from a VG to the devices
file and updates the VG metadata to include the device IDs.
vgimportdevices -a will import all VGs into the system devices file.
LVM commands run by dmeventd not use a devices file by default,
and will look at all devices on the system. A devices file can
be created for dmeventd (/etc/lvm/devices/dmeventd.devices) If
this file exists, lvm commands run by dmeventd will use it.
Internal implementaion:
- device_ids_read - read the devices file
. add struct dev_use (du) to cmd->use_devices for each devices file entry
- dev_cache_scan - get /dev entries
. add struct device (dev) to dev_cache for each device on the system
- device_ids_match - match devices file entries to /dev entries
. match each du on cmd->use_devices to a dev in dev_cache, using device ID
. on match, set du->dev, dev->id, dev->flags MATCHED_USE_ID
- label_scan - read lvm headers and metadata from devices
. filters are applied, those that do not need data from the device
. filter-deviceid skips devs without MATCHED_USE_ID, i.e.
skips /dev entries that are not listed in the devices file
. read lvm label from dev
. filters are applied, those that use data from the device
. read lvm metadata from dev
. add info/vginfo structs for PVs/VGs (info is "lvmcache")
- device_ids_find_renamed_devs - handle devices with unstable devname ID
where devname changed
. this step only needed when devs do not have proper device IDs,
and their dev names change, e.g. after reboot sdb becomes sdc.
. detect incorrect match because PVID in the devices file entry
does not match the PVID found when the device was read above
. undo incorrect match between du and dev above
. search system devices for new location of PVID
. update devices file with new devnames for PVIDs on renamed devices
. label_scan the renamed devs
- continue with command processing
2020-06-23 21:25:41 +03:00
vgimportdevices.c \
2001-11-27 20:02:24 +03:00
vgmerge.c \
2003-11-12 22:16:48 +03:00
vgmknodes.c \
2001-10-12 14:32:06 +04:00
vgreduce.c \
vgremove.c \
2001-10-29 16:52:23 +03:00
vgrename.c \
2002-05-31 23:30:51 +04:00
vgscan.c \
vgsplit.c
2001-09-21 16:37:43 +04:00
2009-09-11 19:52:22 +04:00
SOURCES2 = \
2010-03-29 18:17:59 +04:00
lvm.c \
lvm2cmd-static.c \
lvm2cmd.c \
2017-03-17 02:10:40 +03:00
lvmcmdlib.c \
man-generator.c
2009-09-11 19:52:22 +04:00
2004-04-06 19:14:23 +04:00
TARGETS = \
2001-12-03 23:23:53 +03:00
.commands \
2010-03-29 18:17:59 +04:00
liblvm2cmd.a \
2017-03-17 02:10:40 +03:00
lvm \
man-generator
2001-09-21 16:37:43 +04:00
2008-11-04 20:25:32 +03:00
INSTALL_LVM_TARGETS = install_tools_dynamic
2018-06-14 15:08:33 +03:00
INSTALL_DMSETUP_TARGETS =
2010-04-10 01:42:48 +04:00
INSTALL_CMDLIB_TARGETS = install_cmdlib_dynamic install_cmdlib_include
2003-01-09 01:44:07 +03:00
2004-04-06 19:14:23 +04:00
i f e q ( "@STATIC_LINK@" , "yes" )
2009-05-11 14:13:28 +04:00
TARGETS += lvm.static
2008-11-04 20:25:32 +03:00
INSTALL_LVM_TARGETS += install_tools_static
2004-04-06 19:14:23 +04:00
INSTALL_CMDLIB_TARGETS += install_cmdlib_static
e n d i f
2018-12-17 13:41:38 +03:00
LVMLIBS = $( SYSTEMD_LIBS) -L$( top_builddir) /libdm -ldevmapper $( LIBS) -laio
2009-05-21 15:11:29 +04:00
LIB_VERSION = $( LIB_VERSION_LVM)
2018-12-15 03:55:11 +03:00
INCLUDES = -I$( top_builddir) /tools
2004-03-26 16:21:12 +03:00
2010-03-29 18:17:59 +04:00
CLEAN_TARGETS = liblvm2cmd.$( LIB_SUFFIX) $( TARGETS_DM) \
2010-04-10 01:42:48 +04:00
liblvm2cmd.$( LIB_SUFFIX) .$( LIB_VERSION) lvm-static.o \
2018-06-14 15:08:33 +03:00
liblvm2cmd-static.a lvm.static \
commands: new method for defining commands
. Define a prototype for every lvm command.
. Match every user command with one definition.
. 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, --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
ID: lvresize_by_pv
DESC: Resize an LV by specified PV extents.
FLAGS: SECONDARY_SYNTAX
lvresize --poolmetadatasize SizeMB LV_thinpool
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --stripes Number, --stripesize SizeKB
OP: PV ...
ID: lvresize_pool_metadata_by_size
DESC: Resize a pool metadata SubLV by a specified size.
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/help output is also
auto generated, so it is always in sync with the definitions.
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.
The prototype syntax used for help/man output includes
required --option and positional args on the first line,
and optional --option and positional args enclosed in [ ]
on subsequent lines.
command_name <required_opt_args> <required_pos_args>
[ <optional_opt_args> ]
[ <optional_pos_args> ]
Command definitions that are not to be advertised/suggested
have the flag SECONDARY_SYNTAX. These commands will not be
printed in the normal help output.
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 per-command-name
implementation functions.
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.
2016-08-12 23:52:18 +03:00
$( LDDEPS) .exported_symbols_generated \
2017-03-17 02:10:40 +03:00
cmds.h command-lines-input.h command-count.h man-generator.c
2004-03-26 16:21:12 +03:00
i f e q ( "@CMDLIB@" , "yes" )
2010-04-10 01:42:48 +04:00
TARGETS += liblvm2cmd.$( LIB_SUFFIX) .$( LIB_VERSION)
2008-11-04 20:25:32 +03:00
INSTALL_LVM_TARGETS += $( INSTALL_CMDLIB_TARGETS)
2004-03-26 16:21:12 +03:00
e n d i f
2010-06-25 22:23:10 +04:00
EXPORTED_HEADER = $( srcdir) /lvm2cmd.h
EXPORTED_FN_PREFIX = lvm2
2010-03-29 18:11:17 +04:00
CFLOW_LIST = lvmcmdlib.c lvm2cmd.c
CFLOW_LIST_TARGET = liblvm2cmd.cflow
CFLOW_TARGET = lvm
2010-03-04 12:51:37 +03:00
i n c l u d e $( top_builddir ) / m a k e . t m p l
2001-09-21 16:37:43 +04:00
2018-06-14 15:08:33 +03:00
device-mapper :
2008-11-01 05:19:19 +03:00
all : device -mapper
2013-12-05 17:19:10 +04:00
CFLAGS_lvm.o += $( EXTRA_EXEC_CFLAGS)
2018-12-15 03:55:11 +03:00
lvm : $( OBJECTS ) lvm .o $( LVMINTERNAL_LIBS )
2018-01-31 13:04:17 +03:00
@echo " [CC] $@ "
2018-05-14 14:16:43 +03:00
$( Q) $( CC) $( CFLAGS) $( LDFLAGS) $( EXTRA_EXEC_LDFLAGS) $( ELDFLAGS) -o $@ $+ \
2020-09-26 22:32:55 +03:00
$( DMEVENT_LIBS) $( READLINE_LIBS) $( EDITLINE_LIBS) $( LVMLIBS)
2004-04-06 19:14:23 +04:00
2017-03-17 02:10:40 +03:00
DEFS_man-generator.o += -DMAN_PAGE_GENERATOR
man-generator.c : command .c
2018-01-31 13:04:17 +03:00
@echo " [LN] $@ "
$( Q) $( LN_S) -f $< $@
2017-03-17 02:10:40 +03:00
man-generator : man -generator .o
2018-01-31 13:04:17 +03:00
@echo " [CC] $@ "
2018-11-29 19:09:27 +03:00
$( Q) $( CC) $( CFLAGS) -o $@ $<
2017-03-17 02:10:40 +03:00
2018-12-15 03:55:11 +03:00
lvm.static : $( OBJECTS ) lvm -static .o $( LVMINTERNAL_LIBS )
2018-01-31 13:04:17 +03:00
@echo " [CC] $@ "
2018-12-15 03:55:11 +03:00
$( Q) $( CC) $( CFLAGS) $( LDFLAGS) -static -L$( interfacebuilddir) -o $@ $+ \
$( DMEVENT_LIBS) $( STATIC_LIBS) $( LVMLIBS)
2004-03-26 16:21:12 +03:00
2009-10-02 23:10:31 +04:00
liblvm2cmd.a : $( top_builddir ) /lib /liblvm -internal .a $( OBJECTS ) lvmcmdlib .o lvm 2cmd .o
2018-01-31 13:04:17 +03:00
@echo " [AR] $@ "
$( Q) cat $( top_builddir) /lib/liblvm-internal.a > $@
$( Q) $( AR) rs $@ $( OBJECTS) lvmcmdlib.o lvm2cmd.o > /dev/null
2006-08-19 01:17:18 +04:00
2009-10-02 23:10:31 +04:00
liblvm2cmd-static.a : $( top_builddir ) /lib /liblvm -internal .a $( OBJECTS ) lvmcmdlib .o lvm 2cmd -static .o
2018-01-31 13:04:17 +03:00
@echo " [AR] $@ "
$( Q) cat $( top_builddir) /lib/liblvm-internal.a > $@
$( Q) $( AR) rs $@ $( OBJECTS) lvmcmdlib.o lvm2cmd-static.o > /dev/null
2004-03-26 16:21:12 +03:00
2008-11-14 23:59:56 +03:00
liblvm2cmd.$(LIB_SUFFIX) : liblvm 2cmd .a $( LDDEPS )
2018-01-31 13:04:17 +03:00
@echo " [CC] $@ "
$( Q) $( CC) -shared -Wl,-soname,$@ .$( LIB_VERSION) \
2010-10-15 13:41:21 +04:00
$( CFLAGS) $( CLDFLAGS) -o $@ \
@CLDWHOLEARCHIVE@ liblvm2cmd.a @CLDNOWHOLEARCHIVE@ \
2018-12-15 03:55:11 +03:00
$( LVMINTERNAL_LIBS) $( LVMLIBS)
2001-09-21 16:37:43 +04:00
2010-04-10 01:42:48 +04:00
liblvm2cmd.$(LIB_SUFFIX).$(LIB_VERSION) : liblvm 2cmd .$( LIB_SUFFIX )
2018-01-31 13:04:17 +03:00
@echo " [LN] $@ "
$( Q) $( LN_S) -f $< $@
2010-04-10 01:42:48 +04:00
2010-04-10 01:34:25 +04:00
.commands : $( srcdir ) /commands .h $( srcdir ) /cmdnames .h Makefile
2018-01-31 13:04:17 +03:00
@echo " [CC] $< "
$( Q) $( CC) -E -P $( srcdir) /cmdnames.h 2> /dev/null | \
2017-03-16 04:09:29 +03:00
$( EGREP) -v '^ *(|#.*|config|devtypes|dumpconfig|formats|fullreport|help|lastlog|lvmchange|lvpoll|pvdata|segtypes|systemid|tags|version) *$$' > .commands
2001-09-21 16:37:43 +04:00
2017-02-10 20:36:11 +03:00
command-count.h : $( srcdir ) /command -lines .in Makefile
2018-01-31 13:04:17 +03:00
@echo " [GEN] $@ "
$( Q) set -o pipefail && \
2017-03-28 17:28:53 +03:00
( cat $( top_srcdir) /tools/license.inc && \
2017-02-10 20:36:11 +03:00
echo "/* Do not edit. This file is generated by the Makefile. */" && \
echo -n "#define COMMAND_COUNT " && \
$( GREP) '^ID:' $( srcdir) /command-lines.in | $( WC) -l \
) > $@
cmds.h : $( srcdir ) /command -lines .in Makefile
2018-01-31 13:04:17 +03:00
@echo " [GEN] $@ "
$( Q) set -o pipefail && \
2017-03-28 17:28:53 +03:00
( cat $( top_srcdir) /tools/license.inc && \
2017-02-10 20:36:11 +03:00
echo "/* Do not edit. This file is generated by the Makefile. */" && \
echo "cmd(CMD_NONE, none)" && \
$( GREP) '^ID:' $( srcdir) /command-lines.in | $( SORT) -u | $( AWK) '{print "cmd(" $$2 "_CMD, " $$2 ")"}' && \
echo "cmd(CMD_COUNT, count)" \
) > $@
command-lines-input.h : $( srcdir ) /command -lines .in Makefile
2018-01-31 13:04:17 +03:00
@echo " [GEN] $@ "
$( Q) set -o pipefail && \
2017-03-28 17:28:53 +03:00
( cat $( top_srcdir) /tools/license.inc && \
2017-02-10 20:36:11 +03:00
echo "/* Do not edit. This file is generated by the Makefile. */" && \
echo -en "const char _command_input[] =\n\n\"" && \
2017-02-14 11:48:24 +03:00
$( EGREP) -v '^#|\-\-\-|^$$' $( srcdir) /command-lines.in | $( AWK) 'BEGIN {ORS = "\\n\"\n\""} //' && \
2017-02-10 20:36:11 +03:00
echo "\\n\";" \
2017-01-12 23:44:58 +03:00
) > $@
commands: new method for defining commands
. Define a prototype for every lvm command.
. Match every user command with one definition.
. 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, --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
ID: lvresize_by_pv
DESC: Resize an LV by specified PV extents.
FLAGS: SECONDARY_SYNTAX
lvresize --poolmetadatasize SizeMB LV_thinpool
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --stripes Number, --stripesize SizeKB
OP: PV ...
ID: lvresize_pool_metadata_by_size
DESC: Resize a pool metadata SubLV by a specified size.
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/help output is also
auto generated, so it is always in sync with the definitions.
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.
The prototype syntax used for help/man output includes
required --option and positional args on the first line,
and optional --option and positional args enclosed in [ ]
on subsequent lines.
command_name <required_opt_args> <required_pos_args>
[ <optional_opt_args> ]
[ <optional_pos_args> ]
Command definitions that are not to be advertised/suggested
have the flag SECONDARY_SYNTAX. These commands will not be
printed in the normal help output.
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 per-command-name
implementation functions.
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.
2016-08-12 23:52:18 +03:00
2017-02-10 20:36:11 +03:00
$(SOURCES : %.c =%.d ) $( SOURCES 2:%.c =%.d ) : command -lines -input .h command -count .h cmds .h
2017-02-14 12:24:25 +03:00
$(SOURCES : %.c =%.o ) $( SOURCES 2:%.c =%.o ) : command -lines -input .h command -count .h cmds .h
commands: new method for defining commands
. Define a prototype for every lvm command.
. Match every user command with one definition.
. 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, --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
ID: lvresize_by_pv
DESC: Resize an LV by specified PV extents.
FLAGS: SECONDARY_SYNTAX
lvresize --poolmetadatasize SizeMB LV_thinpool
OO: --alloc Alloc, --autobackup Bool, --force,
--nofsck, --nosync, --noudevsync,
--reportformat String, --stripes Number, --stripesize SizeKB
OP: PV ...
ID: lvresize_pool_metadata_by_size
DESC: Resize a pool metadata SubLV by a specified size.
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/help output is also
auto generated, so it is always in sync with the definitions.
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.
The prototype syntax used for help/man output includes
required --option and positional args on the first line,
and optional --option and positional args enclosed in [ ]
on subsequent lines.
command_name <required_opt_args> <required_pos_args>
[ <optional_opt_args> ]
[ <optional_pos_args> ]
Command definitions that are not to be advertised/suggested
have the flag SECONDARY_SYNTAX. These commands will not be
printed in the normal help output.
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 per-command-name
implementation functions.
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.
2016-08-12 23:52:18 +03:00
2010-03-04 12:53:08 +03:00
i f n e q ( "$(CFLOW_CMD)" , "" )
2010-03-29 18:11:17 +04:00
CFLOW_SOURCES = $( addprefix $( srcdir) /, $( SOURCES) )
- i n c l u d e $( top_builddir ) / l i b / l i b l v m - i n t e r n a l . c f l o w
2006-04-19 19:33:07 +04:00
e n d i f
2010-04-10 01:42:48 +04:00
.PHONY : install_cmdlib_dynamic install_cmdlib_static install_cmdlib_include \
2018-06-14 15:08:33 +03:00
install_tools_dynamic install_tools_static
2010-03-29 18:17:59 +04:00
2010-04-10 01:42:48 +04:00
install_cmdlib_include : $( srcdir ) /lvm 2cmd .h
2018-01-31 13:04:17 +03:00
@echo " [INSTALL] $< "
$( Q) $( INSTALL_DATA) -D $< $( includedir) /$( <F)
2010-04-10 01:42:48 +04:00
2008-11-14 23:59:56 +03:00
install_cmdlib_dynamic : liblvm 2cmd .$( LIB_SUFFIX )
2018-01-31 13:04:17 +03:00
@echo " [INSTALL] $< "
$( Q) $( INSTALL_PROGRAM) -D $< $( libdir) /$( <F) .$( LIB_VERSION)
$( Q) $( INSTALL_DIR) $( usrlibdir)
$( Q) $( LN_S) -f $( USRLIB_RELPATH) $( <F) .$( LIB_VERSION) $( usrlibdir) /$( <F)
2004-03-26 16:21:12 +03:00
2006-08-19 01:17:18 +04:00
install_cmdlib_static : liblvm 2cmd -static .a
2018-01-31 13:04:17 +03:00
@echo " [INSTALL] $< "
$( Q) $( INSTALL_DATA) -D $< $( usrlibdir) /liblvm2cmd.a
2004-04-06 19:14:23 +04:00
install_tools_dynamic : lvm .commands
2018-01-31 13:04:17 +03:00
@echo " [INSTALL] $< "
$( Q) $( INSTALL_PROGRAM) -D lvm $( sbindir) /lvm
2002-01-02 17:23:10 +03:00
@echo Creating symbolic links for individual commands in $( sbindir)
2010-04-10 01:42:48 +04:00
@for v in ` cat .commands` ; do \
2018-11-29 19:09:27 +03:00
test -n " $( Q) " || echo " $( LN_S) -f lvm $( sbindir) / $$ v " ; \
2010-04-10 01:42:48 +04:00
$( LN_S) -f lvm $( sbindir) /$$ v; \
done ;
2001-09-21 16:37:43 +04:00
2004-04-06 19:14:23 +04:00
install_tools_static : lvm .static
2018-01-31 13:04:17 +03:00
@echo " [INSTALL] $< "
$( Q) $( INSTALL_PROGRAM) -D $< $( staticdir) /$( <F)
2004-04-06 19:14:23 +04:00
2009-05-11 14:28:45 +04:00
install_lvm2 : $( INSTALL_LVM_TARGETS )
2018-06-14 15:08:33 +03:00
install : install_lvm 2
