From mboxrd@z Thu Jan 1 00:00:00 1970 From: Harry Butterworth Subject: Re: Proposal for init/kexec/hotplug format for Xen Date: Sun, 27 Feb 2005 18:55:01 +0000 Message-ID: <1109530501.9623.75.camel@localhost> References: <1109451460.32219.11.camel@localhost.localdomain> <68d3daa4e95f4ba6740c6c0ffd3f67b8@cl.cam.ac.uk> <4221E676.5000008@us.ibm.com> <4221ED32.2010407@us.ibm.com> <260c30236e5ef2b632b85e5ebaebcb6b@cl.cam.ac.uk> <4221F26B.2030306@us.ibm.com> <1109521867.4385.22.camel@localhost> <4221F87D.2040809@us.ibm.com> <1109527920.9623.57.camel@localhost> <4222107A.1010902@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit In-Reply-To: <4222107A.1010902@us.ibm.com> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Anthony Liguori Cc: Keir Fraser , Rusty Russell , Jeremy Katz , Xen Mailing List List-Id: xen-devel@lists.xenproject.org On Sun, 2005-02-27 at 12:24 -0600, Anthony Liguori wrote: > Harry Butterworth wrote: > > >>We could begin work today on libxen-hcall and libxen-idc while we work > >>out what the store is going to like and how the OF structure is going to > >>work. Thoughts? > >> > >> > > > >The most difficult aspect of the inter-domain communication API to > >express from the point of view of forwards compatibility with a > >fault-tolerant implementation is that, in a fault-tolerant system with > >different levels of fault tolerance, some domains will come and go > >whilst others persist across failures. > > > > When I said "from the point of view of forwards compatibility with a fault-tolerant implementation" above I meant from the point of view of forwards compatibility with a fault-tolerant _domain_ implementation. > > > I'm not sure fault-tolerance has to be implemented at the IDC primative > level. That seems like something that's implemented at a slightly > higher-level in the stack. Right, the IDC primitives themselves do not have to be fault tolerant... > It would probably be better to expect to implement a separate set of > fault tolerant devices and just design the non-tolerant devices for > maximum code-reuse. ...the trick is to implement a set of IDC primitives that A) can be used as the underlying communication mechanism to implement fault tolerant domains by, for example, using the replicated state machine approach to create a fault-tolerant domain out of a set of base domains and B) are then compatible with providing _exactly_ _the_ _same_ _API_ inside the fault-tolerant domain such that the software running inside the FT domain can be the same software that would run in a base domain. With this approach, you only have to implement fault-tolerance once and from then on you get it for free wherever you want it and you get _maximum_ code reuse because you can reuse all of your non-fault tolerant code as fault-tolerant code simply by running it unchanged but in a fault-tolerant domain. Do not underestimate the importance of this. -- Harry Butterworth ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click