Re: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On 2005-07-20T11:39:38, Joel Becker <[EMAIL PROTECTED]> wrote: > In turn, let me clarify a little where configfs fits in to > things. Configfs is merely a convenient and transparent method to > communicate configuration to kernel objects. It's not a place for > uevents, for netlink sockets, or for fancy communication. It allows > userspace to create an in-kernel object and set/get values on that > object. It also allows userspace and kernelspace to share the same > representation of that object and its values. > For more complex interaction, sysfs and procfs are often more > appropriate. While you might "configure" all known nodes in configfs, > the node up/down state might live in sysfs. A netlink socket for > up/down events might live in procfs. And so on. Right. Thanks for the clarification and elaboration, for I am sure not entirely clear as to how all these mechanisms relate in detail and what is appropriate just where, and when to use something more classic like ioctl etc... ;-) FWIW, we didn't mean to get uevents out via configfs of course. Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" - 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: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On 2005-07-20T11:39:38, Joel Becker [EMAIL PROTECTED] wrote: In turn, let me clarify a little where configfs fits in to things. Configfs is merely a convenient and transparent method to communicate configuration to kernel objects. It's not a place for uevents, for netlink sockets, or for fancy communication. It allows userspace to create an in-kernel object and set/get values on that object. It also allows userspace and kernelspace to share the same representation of that object and its values. For more complex interaction, sysfs and procfs are often more appropriate. While you might configure all known nodes in configfs, the node up/down state might live in sysfs. A netlink socket for up/down events might live in procfs. And so on. Right. Thanks for the clarification and elaboration, for I am sure not entirely clear as to how all these mechanisms relate in detail and what is appropriate just where, and when to use something more classic like ioctl etc... ;-) FWIW, we didn't mean to get uevents out via configfs of course. Sincerely, Lars Marowsky-Brée [EMAIL PROTECTED] -- High Availability Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin Ignorance more frequently begets confidence than does knowledge - 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: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On Wed, Jul 20, 2005 at 08:09:18PM +0200, Lars Marowsky-Bree wrote: > On 2005-07-20T09:55:31, "Walker, Bruce J (HP-Labs)" <[EMAIL PROTECTED]> wrote: > > > Like Lars, I too was under the wrong impression about this configfs > > "nodemanager" kernel component. Our discussions in the cluster > > meeting Monday and Tuesday were assuming it was a general service that > > other kernel components could/would utilize and possibly also > > something that could send uevents to non-kernel components wanting a > > std. way to see membership information/events. > > Let me clarify that this was something we briefly touched on in > Walldorf: The node manager would (re-)export the current data via sysfs > (which would result in uevents being sent, too), and not something we > dreamed up just Monday ;-) In turn, let me clarify a little where configfs fits in to things. Configfs is merely a convenient and transparent method to communicate configuration to kernel objects. It's not a place for uevents, for netlink sockets, or for fancy communication. It allows userspace to create an in-kernel object and set/get values on that object. It also allows userspace and kernelspace to share the same representation of that object and its values. For more complex interaction, sysfs and procfs are often more appropriate. While you might "configure" all known nodes in configfs, the node up/down state might live in sysfs. A netlink socket for up/down events might live in procfs. And so on. Joel -- "But all my words come back to me In shades of mediocrity. Like emptiness in harmony I need someone to comfort me." Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - 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: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On 2005-07-20T09:55:31, "Walker, Bruce J (HP-Labs)" <[EMAIL PROTECTED]> wrote: > Like Lars, I too was under the wrong impression about this configfs > "nodemanager" kernel component. Our discussions in the cluster > meeting Monday and Tuesday were assuming it was a general service that > other kernel components could/would utilize and possibly also > something that could send uevents to non-kernel components wanting a > std. way to see membership information/events. Let me clarify that this was something we briefly touched on in Walldorf: The node manager would (re-)export the current data via sysfs (which would result in uevents being sent, too), and not something we dreamed up just Monday ;-) > As to kernel components without corresponding user-level "managers", > look no farther than OpenSSI. Our hope was that we could adapt to a > user-land membership service and this interface thru configfs would > drive all our kernel subsystems. Well, node manager still can provide you the input as to which nodes are configured, which in a way translates to "membership". The thing it doesn't seem to provide yet is the supsend/modify/resume cycle which for example the RHAT DLM seems to require. Sincerely, Lars Marowsky-Brée <[EMAIL PROTECTED]> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin "Ignorance more frequently begets confidence than does knowledge" - 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: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On 2005-07-20T09:55:31, Walker, Bruce J (HP-Labs) [EMAIL PROTECTED] wrote: Like Lars, I too was under the wrong impression about this configfs nodemanager kernel component. Our discussions in the cluster meeting Monday and Tuesday were assuming it was a general service that other kernel components could/would utilize and possibly also something that could send uevents to non-kernel components wanting a std. way to see membership information/events. Let me clarify that this was something we briefly touched on in Walldorf: The node manager would (re-)export the current data via sysfs (which would result in uevents being sent, too), and not something we dreamed up just Monday ;-) As to kernel components without corresponding user-level managers, look no farther than OpenSSI. Our hope was that we could adapt to a user-land membership service and this interface thru configfs would drive all our kernel subsystems. Well, node manager still can provide you the input as to which nodes are configured, which in a way translates to membership. The thing it doesn't seem to provide yet is the supsend/modify/resume cycle which for example the RHAT DLM seems to require. Sincerely, Lars Marowsky-Brée [EMAIL PROTECTED] -- High Availability Clustering SUSE Labs, Research and Development SUSE LINUX Products GmbH - A Novell Business -- Charles Darwin Ignorance more frequently begets confidence than does knowledge - 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: [Clusters_sig] RE: [Linux-cluster] Re: [Ocfs2-devel] [RFC] nodemanager, ocfs2, dlm
On Wed, Jul 20, 2005 at 08:09:18PM +0200, Lars Marowsky-Bree wrote: On 2005-07-20T09:55:31, Walker, Bruce J (HP-Labs) [EMAIL PROTECTED] wrote: Like Lars, I too was under the wrong impression about this configfs nodemanager kernel component. Our discussions in the cluster meeting Monday and Tuesday were assuming it was a general service that other kernel components could/would utilize and possibly also something that could send uevents to non-kernel components wanting a std. way to see membership information/events. Let me clarify that this was something we briefly touched on in Walldorf: The node manager would (re-)export the current data via sysfs (which would result in uevents being sent, too), and not something we dreamed up just Monday ;-) In turn, let me clarify a little where configfs fits in to things. Configfs is merely a convenient and transparent method to communicate configuration to kernel objects. It's not a place for uevents, for netlink sockets, or for fancy communication. It allows userspace to create an in-kernel object and set/get values on that object. It also allows userspace and kernelspace to share the same representation of that object and its values. For more complex interaction, sysfs and procfs are often more appropriate. While you might configure all known nodes in configfs, the node up/down state might live in sysfs. A netlink socket for up/down events might live in procfs. And so on. Joel -- But all my words come back to me In shades of mediocrity. Like emptiness in harmony I need someone to comfort me. Joel Becker Senior Member of Technical Staff Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - 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/
