shaba/lvm2
1
0
Fork 0
mirror of git://sourceware.org/git/lvm2.git synced 2024-12-22 17:35:59 +03:00
Code Releases Activity
a49f494c4d
lvm2/udev/Makefile.in

69 lines
2.2 KiB
Makefile
Raw Normal View History

dummy makefile for now to keep builds happy
2009-07-31 22:41:19 +04:00
#
Update install rules for udev. Fix unwanted modification of $(top_builddir)/make.tmpl. Using dependency rules to install rules for udev. There is minor problem, with concurent usage of builddir and srcdir could lead to missuse of 10-dm.rules which could be found in VPATH from different builddir. However current solution uses intermediate target so the generated 10-dm.rules exists only for short period of time during make install execution.
2010-04-10 01:44:28 +04:00
# Copyright (C) 2009-2010 Red Hat, Inc. All rights reserved.
dummy makefile for now to keep builds happy
2009-07-31 22:41:19 +04:00
#
# This file is part of LVM2.
#
# 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.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software Foundation,
doc: change fsf address Hmm rpmlint suggest fsf is using a different address these days, so lets keep it up-to-date
2016-01-21 13:49:46 +03:00
# Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
dummy makefile for now to keep builds happy
2009-07-31 22:41:19 +04:00
Allow for a build directory separate from the source.
2009-10-02 23:10:31 +04:00
srcdir = @srcdir@
top_srcdir = @top_srcdir@
top_builddir = @top_builddir@
Add default udev rules. Update dm-ioctl.h comments.
2009-08-03 22:44:54 +04:00
udev: udev rules cleanup Remove executable path detection in udev rules and use sbindir that is configured, but still provide the original functionality by means of 'configure --enable-udev-rule-exec-detection'. Normally, the exec path for the tools called in udev rules should not differ from the sbindir used, however, there are cases this is necessary. For example different environments could be assembled in a way that these path differ for some reason (distribution installer, initrd ...). This functionality is kept for compatibility only. Any environment moving the binaries around and using different paths should be fixed eventually!
2012-06-22 13:50:02 +04:00
include $(top_builddir)/make.tmpl
Several changes to udev support code: - we have these levels when the udev rules are processed: 10-dm.rules --> [11-dm-<subsystem>.rules] --> [12-dm-permissions.rules] --> 13-dm-disk.rules --> [...all the other foreign rules...] --> 95-dm-notify.rules - each level can be disabled now by DM_UDEV_DISABLE_{DM, SUBSYSTEM, DISK, OTHER}_RULES_FLAG - add DM_UDEV_DISABLE_DM_RULES_FLAG to disable 10-dm.rules - add DM_UDEV_DISABLE_OTHER_RULES_FLAG to disable all the other (non-dm) rules. We cutoff these rules by using the 'last_rule', so this one should really be used with great care and in well-founded situations. We use this for lvm's hidden and layer devices now. - add a parameter for add_dev_node, rm_dev_node and rename_dev_node so it's possible to switch on/off udev checks - use DM_UDEV_DISABLE_DM_RULES_FLAG and DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG if there's no cookie set and we have resume, remove and rename ioctl. This could happen when someone uses the libdevmapper that is compiled with udev_sync but the software does not make use of it. This way we can switch off the rules and fallback to libdevmapper node creation so there's no udev/libdevmapper race.
2009-10-26 17:29:33 +03:00
DM_RULES=10-dm.rules 13-dm-disk.rules 95-dm-notify.rules
LVM_RULES=11-dm-lvm.rules
Add skeleton for lvmetad udev rules - 69-dm-lvm-metad.rules. Why using the order 69: - Storage processing in general happens in 60-persistent-storage.rules, including the blkid call that adds some usable information we can use for filtering and speedup (these rules are part of upstream udev and the order is preserved on most distros) - There's still some other storage-related processing done after 60-persistent-storage.rules in general. These might add some detailed storage-related information we might use to filter devices effectively (e.g. MD udev rules, ...). - We need lvmetad rules to be processed before any consumers can use the output - so the metadata cache is ready soon enough (e.g. udisks rules). - There's no official (upstream udev) document about assigning the order, so this number is chosen in best belief it will suit all scenarios.
2012-02-24 13:53:12 +04:00
ifeq ("@BUILD_LVMETAD@", "yes")
LVM_RULES+=69-dm-lvm-metad.rules
endif
makefiles: use configure vars Use binaries found in configure.
2017-02-14 11:48:24 +03:00
DM_DIR=$(shell $(GREP) "\#define DM_DIR" $(top_srcdir)/libdm/misc/dm-ioctl.h | $(AWK) '{print $$3}')
udev: udev rules cleanup Remove executable path detection in udev rules and use sbindir that is configured, but still provide the original functionality by means of 'configure --enable-udev-rule-exec-detection'. Normally, the exec path for the tools called in udev rules should not differ from the sbindir used, however, there are cases this is necessary. For example different environments could be assembled in a way that these path differ for some reason (distribution installer, initrd ...). This functionality is kept for compatibility only. Any environment moving the binaries around and using different paths should be fixed eventually!
2012-06-22 13:50:02 +04:00
udev: explicit pvscan rule in 69-dm-lvm-metad.rules Make the distinction between the cases with and without systemd background jobs explicit in 69-dm-lvm-metad.rules rather than substituting the rule from the Makefile. At this stage, this improves only readibility, at the cost of one GOTO statement. This patch introduces no functional change to the udev rules. Signed-off-by: Martin Wilck <mwilck@suse.com>
2018-04-17 12:32:52 +03:00
BINDIR=@bindir@
udev: udev rules cleanup Remove executable path detection in udev rules and use sbindir that is configured, but still provide the original functionality by means of 'configure --enable-udev-rule-exec-detection'. Normally, the exec path for the tools called in udev rules should not differ from the sbindir used, however, there are cases this is necessary. For example different environments could be assembled in a way that these path differ for some reason (distribution installer, initrd ...). This functionality is kept for compatibility only. Any environment moving the binaries around and using different paths should be fixed eventually!
2012-06-22 13:50:02 +04:00
ifeq ("@UDEV_RULE_EXEC_DETECTION@", "yes")
SBIN=\$$env{DM_SBIN_PATH}
DM_EXEC_RULE=ENV{DM_SBIN_PATH}=\"\/sbin\"\\nTEST!=\"\$$env{DM_SBIN_PATH}\/dmsetup\", ENV{DM_SBIN_PATH}=\"\/usr\/sbin\"
DM_EXEC=\$$env{DM_SBIN_PATH}
LVM_EXEC_RULE=ENV{LVM_SBIN_PATH}=\"\/sbin\"\\nTEST!=\"\$$env{LVM_SBIN_PATH}\/lvm\", ENV{LVM_SBIN_PATH}=\"\/usr\/sbin\"
LVM_EXEC=\$$env{LVM_SBIN_PATH}
Call built-in blkid conditionaly (udev version >= 176), call standard blkid with full path otherwise.
2012-02-20 23:38:40 +04:00
else
udev: udev rules cleanup Remove executable path detection in udev rules and use sbindir that is configured, but still provide the original functionality by means of 'configure --enable-udev-rule-exec-detection'. Normally, the exec path for the tools called in udev rules should not differ from the sbindir used, however, there are cases this is necessary. For example different environments could be assembled in a way that these path differ for some reason (distribution installer, initrd ...). This functionality is kept for compatibility only. Any environment moving the binaries around and using different paths should be fixed eventually!
2012-06-22 13:50:02 +04:00
SBIN="@sbindir@"
DM_EXEC_RULE=""
DM_EXEC=${SBIN}
LVM_EXEC_RULE=""
LVM_EXEC=${SBIN}
Call built-in blkid conditionaly (udev version >= 176), call standard blkid with full path otherwise.
2012-02-20 23:38:40 +04:00
endif
udev: udev rules cleanup Remove executable path detection in udev rules and use sbindir that is configured, but still provide the original functionality by means of 'configure --enable-udev-rule-exec-detection'. Normally, the exec path for the tools called in udev rules should not differ from the sbindir used, however, there are cases this is necessary. For example different environments could be assembled in a way that these path differ for some reason (distribution installer, initrd ...). This functionality is kept for compatibility only. Any environment moving the binaries around and using different paths should be fixed eventually!
2012-06-22 13:50:02 +04:00
ifeq ("@UDEV_HAS_BUILTIN_BLKID@", "yes")
BLKID_RULE=IMPORT{builtin}=\"blkid\"
else
BLKID_RULE=IMPORT{program}=\"${SBIN}\/blkid -o udev -p \$$tempnode\"
endif
Use vpath instead of VPATH. Usage of VPATH makes troubles when used within $(builddir). Not only source files are being found through VPATH, but targets as well. (make --debug=v) Thus if user builds the code in $(srcdir) and also in some $(builddir) he gets mangled results as some generated files (i.e. .export.sym) are 'reused' from $(srcdir) instead of $(builddir). This patch switches to use vpath were we could explicitly name suffixes that should be looked via vpath - we must take care, we do not generate files with these suffixes: .c, .in, .po, .exported_symbols
2010-04-10 01:34:25 +04:00
udev+systemd: make pvscan --cache -aay run as systemd background job from udev The new lvm2-pvscan@.service is responsible for on-demand execution of "pvscan --cache --activate ay" which causes lvmetad to be updated and LVM activation done if the VG is complete. Also, use udev-systemd mechanism to instantiate the job as the lvm2-pvscan@$devnode.service on each newly appeared PV in the system. This prevents the background job to be killed (that would happen if it was directly forked from udev rule - this behaviour is seen in recent versions of udev with the help of systemd that can track detached processes - the detached process would still be in the same cgroup). To enable this official udev-systemd protocol for instantiating background jobs, use new --enable-udev-systemd-background-jobs configure switch (it's disabled by default). This option is highly recommended wherever systemd is used!
2013-10-18 13:07:21 +04:00
ifeq ("@UDEV_SYSTEMD_BACKGROUND_JOBS@", "yes")
udev: explicit pvscan rule in 69-dm-lvm-metad.rules Make the distinction between the cases with and without systemd background jobs explicit in 69-dm-lvm-metad.rules rather than substituting the rule from the Makefile. At this stage, this improves only readibility, at the cost of one GOTO statement. This patch introduces no functional change to the udev rules. Signed-off-by: Martin Wilck <mwilck@suse.com>
2018-04-17 12:32:52 +03:00
PVSCAN_RULE=systemd_background
udev: keep systemd vars on change event in 69-dm-lvm-metad.rules for systemd reload The current logic that avoids setting SYSTEMD_ALIAS and SYSTEMD_WANTS on "change" events is flawed in the default "systemd background job" configuration. For systemd, it's important that device properties don't change spuriously. If an "add" event starts lvm2-pvscan@.service for a device, and a "change" event follows, removing SYSTEMD_ALIAS and SYSTEMD_WANTS from the udev db, information about unit dependencies between the device and the pvscan service can be lost in systemd, in particular if the daemon configuration is reloaded. Steps to reproduce problem: - create a device with an LVM PV - remove device - add device (generates "add" and "change" uevents for the device) (at this point SYSTEMD_ALIAS and SYSTEMD_WANTS are clear in udev db) - systemctl daemon-reload (systemd reloads udev db) - vgchange -a n - remove device => the lvm2-pvscan@.service for the device is still active although the device is gone. - add device again => the PV is not detected, because systemd sees the lvm2-pvscan@.service as active and thus doesn't restart it. The original purpose of this logic was to avoid volumes being scanned over and over again. With systemd background jobs, that isn't necessary, because systemd will not restart the job as long as it's active. Signed-off-by: Martin Wilck <mwilck@suse.com>
2018-04-17 12:38:12 +03:00
PVSCAN_ACTION=add|change
udev+systemd: make pvscan --cache -aay run as systemd background job from udev The new lvm2-pvscan@.service is responsible for on-demand execution of "pvscan --cache --activate ay" which causes lvmetad to be updated and LVM activation done if the VG is complete. Also, use udev-systemd mechanism to instantiate the job as the lvm2-pvscan@$devnode.service on each newly appeared PV in the system. This prevents the background job to be killed (that would happen if it was directly forked from udev rule - this behaviour is seen in recent versions of udev with the help of systemd that can track detached processes - the detached process would still be in the same cgroup). To enable this official udev-systemd protocol for instantiating background jobs, use new --enable-udev-systemd-background-jobs configure switch (it's disabled by default). This option is highly recommended wherever systemd is used!
2013-10-18 13:07:21 +04:00
else
udev: explicit pvscan rule in 69-dm-lvm-metad.rules Make the distinction between the cases with and without systemd background jobs explicit in 69-dm-lvm-metad.rules rather than substituting the rule from the Makefile. At this stage, this improves only readibility, at the cost of one GOTO statement. This patch introduces no functional change to the udev rules. Signed-off-by: Martin Wilck <mwilck@suse.com>
2018-04-17 12:32:52 +03:00
PVSCAN_RULE=direct_pvscan
udev: keep systemd vars on change event in 69-dm-lvm-metad.rules for systemd reload The current logic that avoids setting SYSTEMD_ALIAS and SYSTEMD_WANTS on "change" events is flawed in the default "systemd background job" configuration. For systemd, it's important that device properties don't change spuriously. If an "add" event starts lvm2-pvscan@.service for a device, and a "change" event follows, removing SYSTEMD_ALIAS and SYSTEMD_WANTS from the udev db, information about unit dependencies between the device and the pvscan service can be lost in systemd, in particular if the daemon configuration is reloaded. Steps to reproduce problem: - create a device with an LVM PV - remove device - add device (generates "add" and "change" uevents for the device) (at this point SYSTEMD_ALIAS and SYSTEMD_WANTS are clear in udev db) - systemctl daemon-reload (systemd reloads udev db) - vgchange -a n - remove device => the lvm2-pvscan@.service for the device is still active although the device is gone. - add device again => the PV is not detected, because systemd sees the lvm2-pvscan@.service as active and thus doesn't restart it. The original purpose of this logic was to avoid volumes being scanned over and over again. With systemd background jobs, that isn't necessary, because systemd will not restart the job as long as it's active. Signed-off-by: Martin Wilck <mwilck@suse.com>
2018-04-17 12:38:12 +03:00
PVSCAN_ACTION=add
udev+systemd: make pvscan --cache -aay run as systemd background job from udev The new lvm2-pvscan@.service is responsible for on-demand execution of "pvscan --cache --activate ay" which causes lvmetad to be updated and LVM activation done if the VG is complete. Also, use udev-systemd mechanism to instantiate the job as the lvm2-pvscan@$devnode.service on each newly appeared PV in the system. This prevents the background job to be killed (that would happen if it was directly forked from udev rule - this behaviour is seen in recent versions of udev with the help of systemd that can track detached processes - the detached process would still be in the same cgroup). To enable this official udev-systemd protocol for instantiating background jobs, use new --enable-udev-systemd-background-jobs configure switch (it's disabled by default). This option is highly recommended wherever systemd is used!
2013-10-18 13:07:21 +04:00
endif
makefiles: avoid using vpath for rules files Fixing vpath usage as it has been checking for existance of generated file also in the $(scrdir) e.g.: No need to remake target '10-dm.rules.in'; using VPATH name '...' If the $(srcdir) had been also $(builddir) and contained already generated rules file, it's been used instead generating new one. (See: http://make.mad-scientist.net/papers/how-not-to-use-vpath/)
2016-03-09 19:52:29 +03:00
%.rules: $(srcdir)/%.rules.in
udev: keep systemd vars on change event in 69-dm-lvm-metad.rules for systemd reload The current logic that avoids setting SYSTEMD_ALIAS and SYSTEMD_WANTS on "change" events is flawed in the default "systemd background job" configuration. For systemd, it's important that device properties don't change spuriously. If an "add" event starts lvm2-pvscan@.service for a device, and a "change" event follows, removing SYSTEMD_ALIAS and SYSTEMD_WANTS from the udev db, information about unit dependencies between the device and the pvscan service can be lost in systemd, in particular if the daemon configuration is reloaded. Steps to reproduce problem: - create a device with an LVM PV - remove device - add device (generates "add" and "change" uevents for the device) (at this point SYSTEMD_ALIAS and SYSTEMD_WANTS are clear in udev db) - systemctl daemon-reload (systemd reloads udev db) - vgchange -a n - remove device => the lvm2-pvscan@.service for the device is still active although the device is gone. - add device again => the PV is not detected, because systemd sees the lvm2-pvscan@.service as active and thus doesn't restart it. The original purpose of this logic was to avoid volumes being scanned over and over again. With systemd background jobs, that isn't necessary, because systemd will not restart the job as long as it's active. Signed-off-by: Martin Wilck <mwilck@suse.com>
2018-04-17 12:38:12 +03:00
$(SED) -e "s+(DM_DIR)+$(DM_DIR)+;s+(BINDIR)+$(BINDIR)+;s+(BLKID_RULE)+$(BLKID_RULE)+;s+(PVSCAN_RULE)+$(PVSCAN_RULE)+;s+(PVSCAN_ACTION)+$(PVSCAN_ACTION)+;s+(DM_EXEC_RULE)+$(DM_EXEC_RULE)+;s+(DM_EXEC)+$(DM_EXEC)+;s+(LVM_EXEC_RULE)+$(LVM_EXEC_RULE)+;s+(LVM_EXEC)+$(LVM_EXEC)+;" $< >$@
Add default udev rules. Update dm-ioctl.h comments.
2009-08-03 22:44:54 +04:00
Update install rules for udev. Fix unwanted modification of $(top_builddir)/make.tmpl. Using dependency rules to install rules for udev. There is minor problem, with concurent usage of builddir and srcdir could lead to missuse of 10-dm.rules which could be found in VPATH from different builddir. However current solution uses intermediate target so the generated 10-dm.rules exists only for short period of time during make install execution.
2010-04-10 01:44:28 +04:00
%_install: %.rules
$(INSTALL_DATA) -D $< $(udevdir)/$(<F)
makefiles: compile files on make Make install should install already compiled/generated files.
2014-04-17 12:07:17 +04:00
all: $(DM_RULES) $(LVM_RULES)
CLEAN_TARGETS = $(DM_RULES) $(LVM_RULES)
Update install rules for udev. Fix unwanted modification of $(top_builddir)/make.tmpl. Using dependency rules to install rules for udev. There is minor problem, with concurent usage of builddir and srcdir could lead to missuse of 10-dm.rules which could be found in VPATH from different builddir. However current solution uses intermediate target so the generated 10-dm.rules exists only for short period of time during make install execution.
2010-04-10 01:44:28 +04:00
install_device-mapper: $(DM_RULES:.rules=_install)
install_lvm2: $(LVM_RULES:.rules=_install)
Add default udev rules. Update dm-ioctl.h comments.
2009-08-03 22:44:54 +04:00
install: install_lvm2 install_device-mapper
Copy Permalink