WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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>