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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Sun, 27 Feb 2005 13:10:39 -0600
Cc: Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, Jeremy Katz <katzj@xxxxxxxxxx>, Xen Mailing List <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 27 Feb 2005 19:13:17 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <e2bb8c07891db95c4949fcfb8b319d7d@xxxxxxxxxxxx>
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> <4222107A.1010902@xxxxxxxxxx> <1109530501.9623.75.camel@localhost> <e2bb8c07891db95c4949fcfb8b319d7d@xxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Keir Fraser wrote:

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.

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.

I agree.

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 currently prototyping a semaphore mechanism. One of the nice things I realized is that if a message queue uses semaphores, then something like xcs is unnecessary.

What I'm thinking about right now is how to assign out ports for notification. It's somewhat non-trivial to figure out the best way to manage that. Any thoughts?

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>