From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266839AbUIAPOh (ORCPT ); Wed, 1 Sep 2004 11:14:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266850AbUIAPOh (ORCPT ); Wed, 1 Sep 2004 11:14:37 -0400 Received: from mx1.redhat.com ([66.187.233.31]:64952 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S266839AbUIAPOe (ORCPT ); Wed, 1 Sep 2004 11:14:34 -0400 From: Daniel Phillips Organization: Red Hat To: linux-cluster@redhat.com, sdake@mvista.com Subject: Re: [Linux-cluster] New virtual synchrony API for the kernel: was Re: [Openais] New API in openais Date: Wed, 1 Sep 2004 11:15:45 -0400 User-Agent: KMail/1.6.2 Cc: John Cherry , openais@lists.osdl.org, linux-kernel@vger.kernel.org, linux-ha-dev@new.community.tummy.com References: <1093941076.3613.14.camel@persist.az.mvista.com> <1093973757.5933.56.camel@cherrybomb.pdx.osdl.net> <1093981842.3613.42.camel@persist.az.mvista.com> In-Reply-To: <1093981842.3613.42.camel@persist.az.mvista.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011115.45780.phillips@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi Steven, (here's the rest of that message) On Tuesday 31 August 2004 15:50, Steven Dake wrote: > It would be useful for linux cluster developers for a common low > level group communication API to be agreed upon by relevant clusters > projects. Without this approach, we may end up with several systems > all using different cluster communication & membership mechanisms > that are incompatible. To be honest, this does look interesting, however could you help me on a few points: - Is there any evil IP we have to worry about with this? - Can I get a formal interface spec from AIS for this, without signing a license? - Have you got benchmarks available for control and normal messaging? - Have you looked at the barrier subsystem in sources.redhat.com/dlm? Could this be used as a primitive in implementing Virtual Synchrony? - Why would we need to worry about the AIS spec, in-kernel? What would stop you from providing an interface that presented some kernel functionality to userspace, with the interface of your choice, presumably AIS? - Why isn't Virtual Synchrony overkill, since we don't attempt to deal with netsplits by allowing subclusters to continue to operate? - In what way would GFS benefit from using Virtual Synchrony in place of its current messaging algorithms? Regards, Daniel