Re: [PATCH 1/3] dlm: use configfs
On Fri, Aug 19, 2005 at 03:13:44PM +0800, David Teigland wrote: > The nodemanager RFC I sent a month ago > http://marc.theaimsgroup.com/?l=linux-kernel=112166723919347=2 > > amounts to half of dlm/config.c (everything under comms/ above) moved into > a separate kernel module. That would be trivial to do, and is still an > option to bat around. Yeah ok, so the address/id/local part is still there. As is much of the API to query those attributes. > I question whether factoring such a small chunk into a separate module is > really worth it, though? IMHO, yes. Mostly because we both have very similar basic requirements there and it seems a waste to have duplicated code (even if it's not a huge amount). Future projects wanting to query basic node information from the kernel could have simply used that API without having to further duplicate code too. That said, I'm not sure it has to be done *now* Was there anything in my comments which made going forward with that approach difficult for dlm? > Making all of config.c (all of /config/dlm/ above) into a separate module > wouldn't seem quite so strange. It would require just a few lines of code > to turn it into a stand alone module. Without the dlm specifics, right? It's perfectly fine with me if dlm has a couple more attributes that it wants on a node object - OCFS2 simply won't query them. --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dlm: use configfs
On Fri, Aug 19, 2005 at 03:13:44PM +0800, David Teigland wrote: The nodemanager RFC I sent a month ago http://marc.theaimsgroup.com/?l=linux-kernelm=112166723919347w=2 amounts to half of dlm/config.c (everything under comms/ above) moved into a separate kernel module. That would be trivial to do, and is still an option to bat around. Yeah ok, so the address/id/local part is still there. As is much of the API to query those attributes. I question whether factoring such a small chunk into a separate module is really worth it, though? IMHO, yes. Mostly because we both have very similar basic requirements there and it seems a waste to have duplicated code (even if it's not a huge amount). Future projects wanting to query basic node information from the kernel could have simply used that API without having to further duplicate code too. That said, I'm not sure it has to be done *now* Was there anything in my comments which made going forward with that approach difficult for dlm? Making all of config.c (all of /config/dlm/ above) into a separate module wouldn't seem quite so strange. It would require just a few lines of code to turn it into a stand alone module. Without the dlm specifics, right? It's perfectly fine with me if dlm has a couple more attributes that it wants on a node object - OCFS2 simply won't query them. --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: [PATCH 1/3] dlm: use configfs
On Thu, Aug 18, 2005 at 02:07:47PM -0700, Joel Becker wrote: > On Wed, Aug 17, 2005 at 11:22:18PM -0700, Andrew Morton wrote: > > Fair enough. This really means that the configfs patch should be split out > > of the ocfs2 megapatch... > > Easy to do, it's a separate commit in the ocfs2.git repository. > Would you rather > > a) Do the diffs yourself (configfs commit, remaining ocfs2 commits) > b) Have two repositories, configfs.git and ocfs2.git, where > ocfs2.git is configfs.git+ocfs2 > c) Just take the configfs patch (which really hasn't changed in > months) Well, I included the patch in my last email. For the latest spin, I've created http://oss.oracle.com/git/configfs.git. The ocfs2 git repositories (http://oss.oracle.com/git/ocfs2-dev.git, http://oss.oracle.com/git/ocfs2.git) are now based on the configfs one. If there's any other way you want me to do it, let me know. Joel -- "If the human brain were so simple we could understand it, we would be so simple that we could not." - W. A. Clouston http://www.jlbec.org/ [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [PATCH 1/3] dlm: use configfs
On Thu, Aug 18, 2005 at 02:23:48PM -0700, Mark Fasheh wrote: > On Thu, Aug 18, 2005 at 02:07:50PM +0800, David Teigland wrote: > > + * /config/dlm//spaces//nodes//nodeid > > + * /config/dlm//spaces//nodes//weight > > + * /config/dlm//comms//nodeid > > + * /config/dlm//comms//local > > + * /config/dlm//comms//addr > > So what happened to factoring out the common parts of ocfs2_nodemanager? > I was quite a big fan of that approach :) Or am I just misunderstanding > what these patches do? The nodemanager RFC I sent a month ago http://marc.theaimsgroup.com/?l=linux-kernel=112166723919347=2 amounts to half of dlm/config.c (everything under comms/ above) moved into a separate kernel module. That would be trivial to do, and is still an option to bat around. I question whether factoring such a small chunk into a separate module is really worth it, though? Making all of config.c (all of /config/dlm/ above) into a separate module wouldn't seem quite so strange. It would require just a few lines of code to turn it into a stand alone module. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dlm: use configfs
On Thu, Aug 18, 2005 at 02:23:48PM -0700, Mark Fasheh wrote: On Thu, Aug 18, 2005 at 02:07:50PM +0800, David Teigland wrote: + * /config/dlm/cluster/spaces/space/nodes/node/nodeid + * /config/dlm/cluster/spaces/space/nodes/node/weight + * /config/dlm/cluster/comms/comm/nodeid + * /config/dlm/cluster/comms/comm/local + * /config/dlm/cluster/comms/comm/addr So what happened to factoring out the common parts of ocfs2_nodemanager? I was quite a big fan of that approach :) Or am I just misunderstanding what these patches do? The nodemanager RFC I sent a month ago http://marc.theaimsgroup.com/?l=linux-kernelm=112166723919347w=2 amounts to half of dlm/config.c (everything under comms/ above) moved into a separate kernel module. That would be trivial to do, and is still an option to bat around. I question whether factoring such a small chunk into a separate module is really worth it, though? Making all of config.c (all of /config/dlm/ above) into a separate module wouldn't seem quite so strange. It would require just a few lines of code to turn it into a stand alone module. Dave - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-cluster] Re: [PATCH 1/3] dlm: use configfs
On Thu, Aug 18, 2005 at 02:07:47PM -0700, Joel Becker wrote: On Wed, Aug 17, 2005 at 11:22:18PM -0700, Andrew Morton wrote: Fair enough. This really means that the configfs patch should be split out of the ocfs2 megapatch... Easy to do, it's a separate commit in the ocfs2.git repository. Would you rather a) Do the diffs yourself (configfs commit, remaining ocfs2 commits) b) Have two repositories, configfs.git and ocfs2.git, where ocfs2.git is configfs.git+ocfs2 c) Just take the configfs patch (which really hasn't changed in months) Well, I included the patch in my last email. For the latest spin, I've created http://oss.oracle.com/git/configfs.git. The ocfs2 git repositories (http://oss.oracle.com/git/ocfs2-dev.git, http://oss.oracle.com/git/ocfs2.git) are now based on the configfs one. If there's any other way you want me to do it, let me know. Joel -- If the human brain were so simple we could understand it, we would be so simple that we could not. - W. A. Clouston http://www.jlbec.org/ [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: [PATCH 1/3] dlm: use configfs
Hi David, On Thu, Aug 18, 2005 at 02:07:50PM +0800, David Teigland wrote: > +/* > + * /config/dlm//spaces//nodes//nodeid > + * /config/dlm//spaces//nodes//weight > + * /config/dlm//comms//nodeid > + * /config/dlm//comms//local > + * /config/dlm//comms//addr > + * The level is useless, but I haven't figured out how to avoid it. > + */ So what happened to factoring out the common parts of ocfs2_nodemanager? I was quite a big fan of that approach :) Or am I just misunderstanding what these patches do? --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dlm: use configfs
> Are you the official maintainer of the DLM subsystem? Could you submit > a patch to add a MAINTAINERS entry? I was looking for a maintainer to yes Signed-off-by: David Teigland <[EMAIL PROTECTED]> diff -urpN a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS 2005-08-17 17:19:23.0 +0800 +++ b/MAINTAINERS 2005-08-18 15:08:41.270122528 +0800 @@ -748,6 +748,13 @@ M: [EMAIL PROTECTED] L: linux-kernel@vger.kernel.org S: Maintained +DLM, DISTRIBUTED LOCK MANAGER +P: David Teigland +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://sources.redhat.com/cluster +S: Maintained + DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER P: Tobias Ringstrom M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dlm: use configfs
On 8/17/05, David Teigland <[EMAIL PROTECTED]> wrote: > Use configfs to configure lockspace members and node addresses. This was > previously done with sysfs and ioctl. > > Signed-off-by: David Teigland <[EMAIL PROTECTED]> Are you the official maintainer of the DLM subsystem? Could you submit a patch to add a MAINTAINERS entry? I was looking for a maintainer to send the dlm portion of my schedule_timeout() fixes to, but there wasn't one listed. Thanks, Nish - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dlm: use configfs
David Teigland <[EMAIL PROTECTED]> wrote: > > Use configfs to configure lockspace members and node addresses. This was > previously done with sysfs and ioctl. Fair enough. This really means that the configfs patch should be split out of the ocfs2 megapatch... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] dlm: use configfs
Use configfs to configure lockspace members and node addresses. This was
previously done with sysfs and ioctl.
Signed-off-by: David Teigland <[EMAIL PROTECTED]>
---
drivers/dlm/Makefile |1
drivers/dlm/config.c | 759 -
drivers/dlm/config.h | 12
drivers/dlm/dlm_internal.h |2
drivers/dlm/lockspace.c|7
drivers/dlm/lowcomms.c | 195 +--
drivers/dlm/lowcomms.h |4
drivers/dlm/main.c | 18 -
drivers/dlm/member.c | 40 +-
drivers/dlm/member_sysfs.c | 76
drivers/dlm/node_ioctl.c | 126 ---
drivers/dlm/requestqueue.c |2
include/linux/dlm_node.h | 44 --
13 files changed, 828 insertions(+), 458 deletions(-)
diff -urpN a/drivers/dlm/Makefile b/drivers/dlm/Makefile
--- a/drivers/dlm/Makefile 2005-08-17 17:19:22.0 +0800
+++ b/drivers/dlm/Makefile 2005-08-18 13:22:00.718154328 +0800
@@ -12,7 +12,6 @@ dlm-y := ast.o \
member_sysfs.o \
memory.o \
midcomms.o \
- node_ioctl.o \
rcom.o \
recover.o \
recoverd.o \
diff -urpN a/drivers/dlm/config.c b/drivers/dlm/config.c
--- a/drivers/dlm/config.c 2005-08-17 17:19:22.0 +0800
+++ b/drivers/dlm/config.c 2005-08-18 13:22:00.719154176 +0800
@@ -11,9 +11,756 @@
***
**/
-#include "dlm_internal.h"
+#include
+#include
+#include
+#include
+
#include "config.h"
+/*
+ * /config/dlm//spaces//nodes//nodeid
+ * /config/dlm//spaces//nodes//weight
+ * /config/dlm//comms//nodeid
+ * /config/dlm//comms//local
+ * /config/dlm//comms//addr
+ * The level is useless, but I haven't figured out how to avoid it.
+ */
+
+static struct config_group *space_list;
+static struct config_group *comm_list;
+static struct comm *local_comm;
+
+struct clusters;
+struct cluster;
+struct spaces;
+struct space;
+struct comms;
+struct comm;
+struct nodes;
+struct node;
+
+static struct config_group *make_cluster(struct config_group *, const char *);
+static void drop_cluster(struct config_group *, struct config_item *);
+static void release_cluster(struct config_item *);
+static struct config_group *make_space(struct config_group *, const char *);
+static void drop_space(struct config_group *, struct config_item *);
+static void release_space(struct config_item *);
+static struct config_item *make_comm(struct config_group *, const char *);
+static void drop_comm(struct config_group *, struct config_item *);
+static void release_comm(struct config_item *);
+static struct config_item *make_node(struct config_group *, const char *);
+static void drop_node(struct config_group *, struct config_item *);
+static void release_node(struct config_item *);
+
+static ssize_t show_comm(struct config_item *i, struct configfs_attribute *a,
+char *buf);
+static ssize_t store_comm(struct config_item *i, struct configfs_attribute *a,
+ const char *buf, size_t len);
+static ssize_t show_node(struct config_item *i, struct configfs_attribute *a,
+char *buf);
+static ssize_t store_node(struct config_item *i, struct configfs_attribute *a,
+ const char *buf, size_t len);
+
+static ssize_t comm_nodeid_read(struct comm *cm, char *buf);
+static ssize_t comm_nodeid_write(struct comm *cm, const char *buf, size_t len);
+static ssize_t comm_local_read(struct comm *cm, char *buf);
+static ssize_t comm_local_write(struct comm *cm, const char *buf, size_t len);
+static ssize_t comm_addr_write(struct comm *cm, const char *buf, size_t len);
+static ssize_t node_nodeid_read(struct node *nd, char *buf);
+static ssize_t node_nodeid_write(struct node *nd, const char *buf, size_t len);
+static ssize_t node_weight_read(struct node *nd, char *buf);
+static ssize_t node_weight_write(struct node *nd, const char *buf, size_t len);
+
+enum {
+ COMM_ATTR_NODEID = 0,
+ COMM_ATTR_LOCAL,
+ COMM_ATTR_ADDR,
+};
+
+struct comm_attribute {
+ struct configfs_attribute attr;
+ ssize_t (*show)(struct comm *, char *);
+ ssize_t (*store)(struct comm *, const char *, size_t);
+};
+
+static struct comm_attribute comm_attr_nodeid = {
+ .attr = { .ca_owner = THIS_MODULE,
+.ca_name = "nodeid",
+.ca_mode = S_IRUGO | S_IWUSR },
+ .show = comm_nodeid_read,
+ .store = comm_nodeid_write,
+};
+
+static struct comm_attribute comm_attr_local = {
+ .attr = { .ca_owner = THIS_MODULE,
+.ca_name = "local",
+.ca_mode = S_IRUGO | S_IWUSR },
+ .show =
[PATCH 1/3] dlm: use configfs
Use configfs to configure lockspace members and node addresses. This was
previously done with sysfs and ioctl.
Signed-off-by: David Teigland [EMAIL PROTECTED]
---
drivers/dlm/Makefile |1
drivers/dlm/config.c | 759 -
drivers/dlm/config.h | 12
drivers/dlm/dlm_internal.h |2
drivers/dlm/lockspace.c|7
drivers/dlm/lowcomms.c | 195 +--
drivers/dlm/lowcomms.h |4
drivers/dlm/main.c | 18 -
drivers/dlm/member.c | 40 +-
drivers/dlm/member_sysfs.c | 76
drivers/dlm/node_ioctl.c | 126 ---
drivers/dlm/requestqueue.c |2
include/linux/dlm_node.h | 44 --
13 files changed, 828 insertions(+), 458 deletions(-)
diff -urpN a/drivers/dlm/Makefile b/drivers/dlm/Makefile
--- a/drivers/dlm/Makefile 2005-08-17 17:19:22.0 +0800
+++ b/drivers/dlm/Makefile 2005-08-18 13:22:00.718154328 +0800
@@ -12,7 +12,6 @@ dlm-y := ast.o \
member_sysfs.o \
memory.o \
midcomms.o \
- node_ioctl.o \
rcom.o \
recover.o \
recoverd.o \
diff -urpN a/drivers/dlm/config.c b/drivers/dlm/config.c
--- a/drivers/dlm/config.c 2005-08-17 17:19:22.0 +0800
+++ b/drivers/dlm/config.c 2005-08-18 13:22:00.719154176 +0800
@@ -11,9 +11,756 @@
***
**/
-#include dlm_internal.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/configfs.h
+#include net/sock.h
+
#include config.h
+/*
+ * /config/dlm/cluster/spaces/space/nodes/node/nodeid
+ * /config/dlm/cluster/spaces/space/nodes/node/weight
+ * /config/dlm/cluster/comms/comm/nodeid
+ * /config/dlm/cluster/comms/comm/local
+ * /config/dlm/cluster/comms/comm/addr
+ * The cluster level is useless, but I haven't figured out how to avoid it.
+ */
+
+static struct config_group *space_list;
+static struct config_group *comm_list;
+static struct comm *local_comm;
+
+struct clusters;
+struct cluster;
+struct spaces;
+struct space;
+struct comms;
+struct comm;
+struct nodes;
+struct node;
+
+static struct config_group *make_cluster(struct config_group *, const char *);
+static void drop_cluster(struct config_group *, struct config_item *);
+static void release_cluster(struct config_item *);
+static struct config_group *make_space(struct config_group *, const char *);
+static void drop_space(struct config_group *, struct config_item *);
+static void release_space(struct config_item *);
+static struct config_item *make_comm(struct config_group *, const char *);
+static void drop_comm(struct config_group *, struct config_item *);
+static void release_comm(struct config_item *);
+static struct config_item *make_node(struct config_group *, const char *);
+static void drop_node(struct config_group *, struct config_item *);
+static void release_node(struct config_item *);
+
+static ssize_t show_comm(struct config_item *i, struct configfs_attribute *a,
+char *buf);
+static ssize_t store_comm(struct config_item *i, struct configfs_attribute *a,
+ const char *buf, size_t len);
+static ssize_t show_node(struct config_item *i, struct configfs_attribute *a,
+char *buf);
+static ssize_t store_node(struct config_item *i, struct configfs_attribute *a,
+ const char *buf, size_t len);
+
+static ssize_t comm_nodeid_read(struct comm *cm, char *buf);
+static ssize_t comm_nodeid_write(struct comm *cm, const char *buf, size_t len);
+static ssize_t comm_local_read(struct comm *cm, char *buf);
+static ssize_t comm_local_write(struct comm *cm, const char *buf, size_t len);
+static ssize_t comm_addr_write(struct comm *cm, const char *buf, size_t len);
+static ssize_t node_nodeid_read(struct node *nd, char *buf);
+static ssize_t node_nodeid_write(struct node *nd, const char *buf, size_t len);
+static ssize_t node_weight_read(struct node *nd, char *buf);
+static ssize_t node_weight_write(struct node *nd, const char *buf, size_t len);
+
+enum {
+ COMM_ATTR_NODEID = 0,
+ COMM_ATTR_LOCAL,
+ COMM_ATTR_ADDR,
+};
+
+struct comm_attribute {
+ struct configfs_attribute attr;
+ ssize_t (*show)(struct comm *, char *);
+ ssize_t (*store)(struct comm *, const char *, size_t);
+};
+
+static struct comm_attribute comm_attr_nodeid = {
+ .attr = { .ca_owner = THIS_MODULE,
+.ca_name = nodeid,
+.ca_mode = S_IRUGO | S_IWUSR },
+ .show = comm_nodeid_read,
+ .store = comm_nodeid_write,
+};
+
+static struct comm_attribute comm_attr_local = {
+ .attr = { .ca_owner = THIS_MODULE,
Re: [PATCH 1/3] dlm: use configfs
David Teigland [EMAIL PROTECTED] wrote: Use configfs to configure lockspace members and node addresses. This was previously done with sysfs and ioctl. Fair enough. This really means that the configfs patch should be split out of the ocfs2 megapatch... - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dlm: use configfs
On 8/17/05, David Teigland [EMAIL PROTECTED] wrote: Use configfs to configure lockspace members and node addresses. This was previously done with sysfs and ioctl. Signed-off-by: David Teigland [EMAIL PROTECTED] Are you the official maintainer of the DLM subsystem? Could you submit a patch to add a MAINTAINERS entry? I was looking for a maintainer to send the dlm portion of my schedule_timeout() fixes to, but there wasn't one listed. Thanks, Nish - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dlm: use configfs
Are you the official maintainer of the DLM subsystem? Could you submit a patch to add a MAINTAINERS entry? I was looking for a maintainer to yes Signed-off-by: David Teigland [EMAIL PROTECTED] diff -urpN a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS 2005-08-17 17:19:23.0 +0800 +++ b/MAINTAINERS 2005-08-18 15:08:41.270122528 +0800 @@ -748,6 +748,13 @@ M: [EMAIL PROTECTED] L: linux-kernel@vger.kernel.org S: Maintained +DLM, DISTRIBUTED LOCK MANAGER +P: David Teigland +M: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] +W: http://sources.redhat.com/cluster +S: Maintained + DAVICOM FAST ETHERNET (DMFE) NETWORK DRIVER P: Tobias Ringstrom M: [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dlm: use configfs
Hi David, On Thu, Aug 18, 2005 at 02:07:50PM +0800, David Teigland wrote: +/* + * /config/dlm/cluster/spaces/space/nodes/node/nodeid + * /config/dlm/cluster/spaces/space/nodes/node/weight + * /config/dlm/cluster/comms/comm/nodeid + * /config/dlm/cluster/comms/comm/local + * /config/dlm/cluster/comms/comm/addr + * The cluster level is useless, but I haven't figured out how to avoid it. + */ So what happened to factoring out the common parts of ocfs2_nodemanager? I was quite a big fan of that approach :) Or am I just misunderstanding what these patches do? --Mark -- Mark Fasheh Senior Software Developer, Oracle [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
