Skip to contentSkip to conversation

dlm: build

PATCH In review David Teigland 4 participants 7 messages Apr 25, 2005 – Apr 27, 2005

lore
Share & tools
lore

David Teigland

author
#0 lore raw

PATCH 7/7 dlm: build

Adds the dlm to the build system.

Signed-off-by Dave Teigland <[email protected]>
Signed-off-by Patrick Caulfield <[email protected]>

---

 drivers/Kconfig      |    2 ++
 drivers/Makefile     |    1 +
 drivers/dlm/Kconfig  |   25 +++++++++++++++++++++++++
 drivers/dlm/Makefile |   23 +++++++++++++++++++++++
 4 files changed, 51 insertions(+)
drivers/dlm/Makefile +23 -0
@@ -0,0 +1,23 @@
+obj-$(CONFIG_DLM) +=		dlm.o
+obj-$(CONFIG_DLM_DEVICE) +=	dlm_device.o
+
+dlm-y :=			ast.o \
+				config.o \
+				dir.o \
+				lock.o \
+				lockspace.o \
+				lowcomms.o \
+				main.o \
+				member.o \
+				member_sysfs.o \
+				memory.o \
+				midcomms.o \
+				node_ioctl.o \
+				rcom.o \
+				recover.o \
+				recoverd.o \
+				requestqueue.o \
+				util.o
+dlm-$(CONFIG_DLM_DEBUG) +=	debug_fs.o
+
+dlm_device-y :=			device.o
drivers/Makefile 2005-04-25 16:10:10.228660648 +0800 renamed from drivers/Makefile 2005-04-25 15:40:15.000000000 +0800 +1 -0
@@ -64,3 +64,4 @@
 obj-$(CONFIG_BLK_DEV_SGIIOC4)	+= sn/
 obj-y				+= firmware/
 obj-$(CONFIG_CRYPTO)		+= crypto/
+obj-$(CONFIG_DLM)		+= dlm/
drivers/dlm/Kconfig +25 -0
@@ -0,0 +1,25 @@
+menu "Distributed Lock Manager"
+
+config DLM 
+	tristate "Distributed Lock Manager (DLM)"
+	help
+	A general purpose distributed lock manager for kernel or userspace
+	applications.
+
+config DLM_DEVICE
+	tristate "DLM device for userspace access"
+	depends on DLM
+	help
+	This module creates a misc device through which the dlm lockspace
+	and locking functions become available to userspace applications
+	(usually through the libdlm library).
+
+config DLM_DEBUG
+	bool "DLM debugging"
+	depends on DLM
+	help
+	Under the debugfs mount point, the name of each lockspace will
+	appear as a file in the "dlm" directory.  The output is the
+	list of resource and locks the local node knows about.
+
+endmenu
drivers/Kconfig 2005-04-25 16:01:50.476634504 +0800 renamed from drivers/Kconfig 2005-03-02 15:38:26.000000000 +0800 +2 -0
@@ -58,4 +58,6 @@
 
 source "drivers/infiniband/Kconfig"
 
+source "drivers/dlm/Kconfig"
+
 endmenu
#1 lore raw
Quoted 16 lines · David Teigland

+config DLM
+ tristate "Distributed Lock Manager (DLM)"
+ help
+ A general purpose distributed lock manager for kernel or userspace
+ applications.
+
+config DLM_DEVICE
+ tristate "DLM device for userspace access"
+ depends on DLM
+ help
+ This module creates a misc device through which the dlm lockspace
+ and locking functions become available to userspace applications
+ (usually through the libdlm library).
+
+config DLM_DEBUG

Quoted 8 lines

+ bool "DLM debugging"
+ depends on DLM
+ help
+ Under the debugfs mount point, the name of each lockspace will
+ appear as a file in the "dlm" directory. The output is the
+ list of resource and locks the local node knows about.
+
+endmenu

Shouldn't it enable SCTP? Depend on NET?

(I agree with Jesper's various comments btw)

#2 lore raw
Quoted 5 lines · Andrew Morton
Quoted 2 lines · David Teigland

+config DLM

Shouldn't it enable SCTP? Depend on NET?

Looks like it. As a related question, is the SCTP dependency something fairly innate to the design, or would layering it over other low-level transports in the future be a possibility? A first glance makes it look like only lowcomms.c and maybe midcomms.c would be affected.

author
#3 lore raw
Quoted 11 lines · On Mon, Apr 25, 2005 at 11:52:15PM -0400, [email protected] wrote:
Quoted 5 lines · Andrew Morton
Quoted 2 lines · David Teigland

+config DLM

Shouldn't it enable SCTP? Depend on NET?

Looks like it. As a related question, is the SCTP dependency something fairly innate to the design, or would layering it over other low-level transports in the future be a possibility? A first glance makes it look like only lowcomms.c and maybe midcomms.c would be affected.

Thanks, the suggestions so far have been very good and we're working on them.

Other transports are definately a possibility and something that should be quite simple since it's all encapsulated in lowcomms as you've mentioned.

Dave

#4 lore raw
Quoted 2 lines · David Teigland

Other transports are definately a possibility and something that should be quite simple since it's all encapsulated in lowcomms as you've mentioned.

That begs the question why you have choosen SCTP for the newer DLM versions. Curiousity kills the cat, so I'm asking ;-)

Sincerely,
Lars Marowsky-Brée <[email protected]>

Signature · 3 lines
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
author
#5 lore raw
Quoted 7 lines · Lars Marowsky-Bree
Quoted 2 lines · David Teigland

Other transports are definately a possibility and something that should be quite simple since it's all encapsulated in lowcomms as you've mentioned.

That begs the question why you have choosen SCTP for the newer DLM versions. Curiousity kills the cat, so I'm asking ;-)

Because it allows you to easily take advantage of multi-homing where a node has redundant networks.

Dave

#6 lore raw
Quoted 4 lines · David Teigland
Quoted 2 lines

That begs the question why you have choosen SCTP for the newer DLM versions. Curiousity kills the cat, so I'm asking ;-)

Because it allows you to easily take advantage of multi-homing where a node has redundant networks.

Hm, has it since been fixed to do that completely automatically or even better sent the messages via all available links...?

Last time I looked getting to reroute the connection still involved some fiddling.

Sincerely,
Lars Marowsky-Brée <[email protected]>

Signature · 3 lines
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business