Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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

To: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Sun, 27 Feb 2005 12:24:58 -0600
Cc: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Jeremy Katz <katzj@xxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 27 Feb 2005 18:28:14 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <1109527920.9623.57.camel@localhost>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organization: IBM
References: <1109451460.32219.11.camel@xxxxxxxxxxxxxxxxxxxxx> <68d3daa4e95f4ba6740c6c0ffd3f67b8@xxxxxxxxxxxx> <4221E676.5000008@xxxxxxxxxx> <d754778cdc1fd4ef6d8d23cb014954a9@xxxxxxxxxxxx> <4221ED32.2010407@xxxxxxxxxx> <260c30236e5ef2b632b85e5ebaebcb6b@xxxxxxxxxxxx> <4221F26B.2030306@xxxxxxxxxx> <1109521867.4385.22.camel@localhost> <4221F87D.2040809@xxxxxxxxxx> <1109527920.9623.57.camel@localhost>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
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.

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.

For instance, I'm not sure how to even think about what a fault-tolerant semaphore would be however I can certainly imagine being able to implement a fault-tolerant protocol that uses semaphores and shared memory.

I think fault-tolerant primatives can quite comfortably sit on top of lower-level primatives. My initial reaction is that a fault-tolerant primative is going to have a fair bit of overhead. I think the interface is going to be fairly different too. I'm not sure you want to pay the price of transparent fault-tolerance in all circumstances.

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.

Regards,
Anthony Liguori



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