[Linux-cluster] [RFC] Generic Kernel API

[Patrick Caulfield]

On Wed, Sep 29, 2004 at 04:55:41PM -0700, Daniel McNeil wrote:
> 
> Patrick,
> 
> I read over your api and have a few comments.
> 
> Simple stuff first.  The membership_node looks very similar to the SAF
> interfaces, so I assume they fields mean the same.  mn_member is 32bits
> but it just specifies if this node is a member (1) or not (0), right?

Yes.
 
> The mni_viewnumber is 32 bits, in SAF it is 64bits.  Might want it to
> be 64bits.  (I think nodeid should be 64bits, but SAF has it as 32bits,
> so I guess it is ok).
> 
> What is mni_context?

It's an opaque structure passed in from the caller that gets passed back via the
callback so that the caller can identify the request (or attach private
information).
 
> I bit more description of these fields would be nice -- don't have to
> be as verbose as SAF :)
> 
> In membership_ops, you have start_notify and notify_stop -- might want
> to be consistent with the naming (either notify_start or stop_notify).

Yes, I fixed that!
 
> Now the more complicated stuff:
> 
> I think we need more information on how this api works and a description
> of how the calls are used.
> 
> cm_attach() is used to attach to a particular cluster provider that
> has been registered.  Who calls cm_attach()?
> 
> I assume whoever calls cm_attach() will then be calling the ops
> functions.
> 
> What is cmprivate in start_notify?
> 
> Once start_notify is called the CM module will call the callback
> function whenever there is a change until notify_stop is called?
> 
> The membership_callback_routine only has "context" and "reason".
> Again, what is context?  What is reason?
> How is the data returned?  I'm guessing a struct membership_notify_info
> is filled in at from the buffer passed in from start_notify,  Is that
> right?  A bit more description here would be good.
> 
> What is the difference between get_quorate() and get_info() which
> returns a struct quorum_info with qi_quorum?

get_quorate returns a boolean value that just says whether the cluster has
quorum or not. get_info returns a struct showing the elements that went up to
making that decision. I'm not really sure how much use it is to applications but
I don't like hiding information!
 
> Should get_quorate() and get_info() take a viewnumber so we can match
> up the list of member and whether it had quorum?  (it could have changed
> after the callback with membership before we call get_quorum.)

The problem there is keeping a list of members for each view, which seems like
rather a waste of memory in kernel space.


I'm in the middle of writing an implementation of this (with a cman plugin) that
I'll post shortly. That should clear up any other points that I may seem to have
ignored above! some of the things have been fixed in the meantime. I should get
it posted this week.
-- 

patrick