|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen
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@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
-------------------------------------------------------
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, (continued)
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Harry Butterworth
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Anthony Liguori
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen,
Harry Butterworth <=
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Keir Fraser
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Anthony Liguori
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Keir Fraser
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Anthony Liguori
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Harry Butterworth
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Keir Fraser
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Harry Butterworth
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Harry Butterworth
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Rusty Russell
- Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen, Anthony Liguori
|
|
|
|
|