[PATCH 7/7] dlm: build

[PATCH 7/7] dlm: build

[David Teigland]

Adds the dlm to the build system.

Signed-Off-By: Dave Teigland <teigland@redhat.com>
Signed-Off-By: Patrick Caulfield <pcaulfie@redhat.com>

---

 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

Re: [PATCH 7/7] dlm: build

[Andrew Morton]

David Teigland <teigland@redhat.com> 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)

Re: [PATCH 7/7] dlm: build

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On Mon, 25 Apr 2005 14:25:25 PDT, Andrew Morton said:
> David Teigland <teigland@redhat.com> 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.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH 7/7] dlm: build

[David Teigland]

On Mon, Apr 25, 2005 at 11:52:15PM -0400, Valdis.Kletnieks@vt.edu wrote:
> On Mon, 25 Apr 2005 14:25:25 PDT, Andrew Morton said:
> > David Teigland <teigland@redhat.com> 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

Re: [PATCH 7/7] dlm: build

[Lars Marowsky-Bree]

On 2005-04-26T13:52:35, David Teigland <teigland@redhat.com> 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 <lmb@suse.de>

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

Re: [PATCH 7/7] dlm: build

[David Teigland]

On Wed, Apr 27, 2005 at 03:25:47PM +0200, Lars Marowsky-Bree wrote:
> On 2005-04-26T13:52:35, David Teigland <teigland@redhat.com> 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

Re: [PATCH 7/7] dlm: build

[Lars Marowsky-Bree]

On 2005-04-27T21:54:28, David Teigland <teigland@redhat.com> 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 <lmb@suse.de>

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