Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Sun, 2005-02-27 at 18:57 +0000, Keir Fraser wrote:
> On 27 Feb 2005, at 18:55, Harry Butterworth wrote:
> 
> > ..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.
> 
> The IDC primitives are likely to be *so* low level that this will be a 
> non-issue. Anything that can needs to be fault-tolerance aware in any 
> way I think will be in higher layers.
> 

Part of what I'm trying to say is that, if you get the architecture
right, the only code in the system that needs to be aware of its own
fault tolerance is the code that takes N base domains and creates a
fault-tolerant domain from it. All the other code in the system is
completely unaware of its own fault tolerance (it only needs
multi-pathing and hotplug to deal with external failures) even when it
is made fault-tolerant by virtue of running in a fault-tolerant domain.

If you get the architecture wrong, on the other hand, then you'll end up
implementing fault-tolerance over and over again in all the different
components that require it which is much more work and much more error
prone.

> Really the libidc is almost a no-op -- we have shared memory and 
> notifications -- semaphores and message queues on top of that is very 
> little code.

So, for example, if the IDC API exposes the shared memory implementation
to the clients then the API will not be compatible with the above trick
because shared memory will not work for the communication between the
base domains and the FT domain as it is not compatible with the
distributed consensus protocol and replication.

This would mean that all the clients written to the shared memory API
would need to be rewritten to a different API before they could run
inside a FT domain.

On the other hand, a shared memory implementation used to implement a
channel model API is OK because the shared memory implementation will be
nice and efficient for inter-base-domain communication and the shared
memory implementation can be transparently replaced with a message
passing implementation for base-to-FT-domain communication which must go
via the consensus protocol.

Similarly, an API which assumes all domains are mutually fully connected
will not work with the above trick because other domains can only
communicate with the FT domains by routing inter-domain communication
though their base domains and the consensus protocol.

> 
> You sound like you are more worried about the device-channel 
> setup/teardown/probe/recovery code. That would be above libidc, if we 
> use libidc at all.

I'm not worried :-)

Right, so the code above libidc including the device-channel
setup/teardown/probe/recovery code should run unchanged in both base
domains and FT domains.  This code will link against the IDC API which
means that the IDC API must be the same in both base and FT domains
which means in turn that the IDC API is subject to the constraints
above.

Assuming you are ever interested in doing any of this at all of course
which you might not be.

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