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@xxxxxxxxxx>
