[Linux-cluster] RE: [RFC] Generic Kernel API

[David Teigland]

On Tue, Sep 21, 2004 at 03:32:30PM -0700, Steven Dake wrote:
> Patrick,
> 
> I hvae read your RFC for an API and find it interesting.  But there is
> one aspect that is somewhat disturbing to me.
> 
> In the model you propose messaging and membership are seperated (or
> atleast not completed).

What's to prevent a single integrated messaging/membership system (like
you describe below) from providing both messaging and membership ops?

I /don't/ think the separation of the ops into different structs was meant
to imply that different systems would provide them.  I think the intention
was that a clustering module would be free to provide whichever methods it
wanted, e.g. a clustering module that didn't have a quorum system would
just leave those functions null, or provide just selected functions within
a given struct.


> As a result, I propose we use virtual synchrony as the basis of kernel
> communication.  To that end, I have developed a small API (which is
> implemented in userland in about 5000 lines of code).  This may be the
> basis, with whatever changes are required for kernel inclusion, for
> communication.

Sounds good.  It would actually be an integrated communication and basic
membership system, right?  As you mentioned above, the two are
interdependent.  By "basic membership" I'm implying that more exotic
membership systems could be implemented above this lowest layer.

I think the question here is whether your messaging/membership system
(currently in user space) would fit behind the API Patrick sent once
ported to the kernel.  If not, then what needs to be changed so it would?
The idea is for the API to be general enough to support a variety of
clustering modules, including yours.

-- 
Dave Teigland  <teigland at redhat.com>