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(+)
--- a/drivers/dlm/Makefile 1970-01-01 07:30:00.000000000 +0730
+++ b/drivers/dlm/Makefile 2005-04-25 22:52:04.209778304 +0800
@@ -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
--- a/drivers/Makefile 2005-04-25 15:40:15.000000000 +0800
+++ b/drivers/Makefile 2005-04-25 16:10:10.228660648 +0800
@@ -64,3 +64,4 @@
obj-$(CONFIG_BLK_DEV_SGIIOC4) += sn/
obj-y += firmware/
obj-$(CONFIG_CRYPTO) += crypto/
+obj-$(CONFIG_DLM) += dlm/
--- a/drivers/dlm/Kconfig 1970-01-01 07:30:00.000000000 +0730
+++ b/drivers/dlm/Kconfig 2005-04-25 22:52:04.217777088 +0800
@@ -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
--- a/drivers/Kconfig 2005-03-02 15:38:26.000000000 +0800
+++ b/drivers/Kconfig 2005-04-25 16:01:50.476634504 +0800
@@ -58,4 +58,6 @@
source "drivers/infiniband/Kconfig"
+source "drivers/dlm/Kconfig"
+
endmenu
David Teigland <[email protected]> wrote:
>
> +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
Shouldn't it enable SCTP? Depend on NET?
(I agree with Jesper's various comments btw)
On Mon, 25 Apr 2005 14:25:25 PDT, Andrew Morton said:
> David Teigland <[email protected]> wrote:
> >
> > +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.
On Mon, Apr 25, 2005 at 11:52:15PM -0400, [email protected] wrote:
> On Mon, 25 Apr 2005 14:25:25 PDT, Andrew Morton said:
> > David Teigland <[email protected]> wrote:
> > >
> > > +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
On 2005-04-26T13:52:35, David Teigland <[email protected]> wrote:
> 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]>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business
On Wed, Apr 27, 2005 at 03:25:47PM +0200, Lars Marowsky-Bree wrote:
> On 2005-04-26T13:52:35, David Teigland <[email protected]> wrote:
>
> > 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
On 2005-04-27T21:54:28, David Teigland <[email protected]> wrote:
> > 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]>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business