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

Steven Dake sdake at mvista.com
Tue Sep 21 22:32:30 UTC 2004


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).  How can you communicate to a group, though, if
you are not aware of the current configuration (membership).  Think of
talking on the phone to a group of friends.  When you say something, you
may want to know which of your friends is in the room, because it may
alter your speech to them.  Maybe not.  But distributed applications do
need to know the relationship between configurations and messages.  I
have implemented distributed projects in the past that do not implement
strong membership guarantees and they are unreliable.

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

The basic concept of the API is that there are groups with 32 byte
keys.  It is possible to publish from 1 processor to all other group
members.  It is possible to join or leave a group.  When a configuration
change occurs or a message needs to be delivered, a callback is executed
(which handles the configuration change or message).  The API also
allows multiple instances of communication paths, priorities, large
messages (256k now) which are compile-time configurable, etc.

I'd ask that you atleast consider reviewing the man pages that have been
produced for this API.  The link is:

To understand how the protocol works and find out more information about
openais, check out:

To find out more about the openais project, check out:

More information about the Linux-cluster mailing list