summaryrefslogtreecommitdiff
path: root/Makefile
blob: 19a66158446ca16f8eef680879a99f48c4a2d1f1 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
BINDIR = $(HOME)/bin

TARGETS = mkheader.py isprime multi-send-key perm.py git2svn-sync

all: $(TARGETS)
	@echo "Nothing to be done"

install:
	@echo "Installing the following scripts to $(BINDIR)"
	@echo " $(TARGETS)"
	@mkdir -p $(BINDIR)
	@install -m755 -t $(BINDIR) $(TARGETS)

uninstall:
	@echo "Uninstalling the following scripts from $(BINDIR):"
	@echo " $(TARGETS)"
	@rmdir --ignore-fail-on-non-empty $(BINDIR)
	@for s in $(TARGETS); do rm -f "$(BINDIR)/$${s}"; done
selected='selected'>includemode:
authorKrzysztof Opasiak <k.opasiak@samsung.com>2015-12-11 16:06:12 +0100
committerNicholas Bellinger <nab@linux-iscsi.org>2015-12-20 18:04:03 -0800
commitd79d75b5c5182fd94225996db71e06f9cbc7faed (patch)
tree8e0b9def43d58ee4d8775896e683a8128fa7048f /include/linux/configfs.h
parent9a70adfff3379a6511483bd60dac06fda49b14a8 (diff)
fs: configfs: Add unlocked version of configfs_depend_item()
This change is necessary for the SCSI target usb gadget composed with configfs. In this case configfs will be used for two different purposes: to compose a usb gadget and to configure the target part. If an instance of tcm function is created in $CONFIGFS_ROOT/usb_gadget/<gadget>/functions a tpg can be created in $CONFIGFS_ROOT/target/usb_gadget/<wwn>/, but after a tpg is created the tcm function must not be removed until its corresponding tpg is gone. While the configfs_depend/undepend_item() are meant exactly for creating this kind of dependencies, they are not suitable if the other kernel subsystem happens to be another subsystem in configfs, so this patch adds unlocked versions meant for configfs callbacks. Above description has been provided by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> In configfs_depend_item() we have to consider two possible cases: 1) When we are called to depend another item in the same subsystem as caller In this case we should skip locking configfs root as we know that configfs is in valid state and our subsystem will not be unregistered during this call. 2) When we are called to depend item in different subsystem than our caller In this case we are also sure that configfs is in valid state but we have to lock root of configfs to avoid unregistration of target's subsystem. As it is other than caller's subsystem, there may be nothing what protects us against unregistration of that subsystem. Signed-off-by: Krzysztof Opasiak <k.opasiak@samsung.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Diffstat (limited to 'include/linux/configfs.h')