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). 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 communication. 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: http://developer.osdl.org/dev/openais/htmldocs/index.html To understand how the protocol works and find out more information about openais, check out: http://developer.osdl.org/dev/openais/pres/aispres040914.pdf To find out more about the openais project, check out: http://developer.osdl.org/dev/openais
