All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Butterworth <harry@hebutterworth.freeserve.co.uk>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>,
	Rusty Russell <rusty@rustcorp.com.au>,
	Jeremy Katz <katzj@redhat.com>,
	Xen Mailing List <xen-devel@lists.sourceforge.net>
Subject: Re: Proposal for init/kexec/hotplug format for Xen
Date: Sun, 27 Feb 2005 18:55:01 +0000	[thread overview]
Message-ID: <1109530501.9623.75.camel@localhost> (raw)
In-Reply-To: <4222107A.1010902@us.ibm.com>

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 <harry@hebutterworth.freeserve.co.uk>





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

  reply	other threads:[~2005-02-27 18:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-26 20:57 Proposal for init/kexec/hotplug format for Xen Rusty Russell
2005-02-27 10:53 ` Keir Fraser
2005-02-27 11:46   ` Rusty Russell
2005-02-27 15:25   ` Anthony Liguori
2005-02-27 15:48     ` Keir Fraser
2005-02-27 15:54       ` Anthony Liguori
2005-02-27 16:09         ` Keir Fraser
2005-02-27 16:16           ` Anthony Liguori
2005-02-27 16:31             ` Harry Butterworth
2005-02-27 16:42               ` Anthony Liguori
2005-02-27 17:32                 ` Keir Fraser
2005-02-27 17:59                   ` Anthony Liguori
2005-02-27 18:12                 ` Harry Butterworth
2005-02-27 18:24                   ` Anthony Liguori
2005-02-27 18:55                     ` Harry Butterworth [this message]
2005-02-27 18:57                       ` Keir Fraser
2005-02-27 19:10                         ` Anthony Liguori
2005-02-27 21:49                           ` Keir Fraser
2005-02-27 22:39                             ` Anthony Liguori
2005-02-27 23:29                               ` Harry Butterworth
2005-02-28  8:59                               ` Keir Fraser
2005-02-27 19:38                         ` Harry Butterworth
2005-02-27 16:05     ` Harry Butterworth
2005-02-28 12:06     ` Rusty Russell
2005-02-28 15:46       ` Anthony Liguori
2005-02-28 20:28       ` Jeremy Katz
2005-02-28 22:24         ` Harry Butterworth
  -- strict thread matches above, loose matches on Subject: below --
2005-02-28 13:08 Re: " harry
2005-02-28 13:32 ` Rusty Russell
2005-02-28 13:40   ` Harry Butterworth
2005-02-28 14:33     ` Keir Fraser
2005-02-28 16:46     ` Re: " Rusty Russell
2005-03-01 13:15       ` Harry Butterworth
2005-03-01 15:08         ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1109530501.9623.75.camel@localhost \
    --to=harry@hebutterworth.freeserve.co.uk \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=aliguori@us.ibm.com \
    --cc=katzj@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.