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: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] Proposal for init/kexec/hotplug format for Xen
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sun, 27 Feb 2005 21:49:28 +0000
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 21:52:40 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <42221B2F.9000501@xxxxxxxxxx>
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>
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> <42221B2F.9000501@xxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx

On 27 Feb 2005, at 19:10, Anthony Liguori wrote:

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.

The purpose of xcs was to shim under xend and allow certain message types to be redirected to other tools. It won't be required in the next-gen tools anyway -- it's usefulness is entirely orthogonal to whether or not we have semaphores.

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?

The difficulty may be that, in the case of normal SysV IPC you have a common OS instance to manage shmem namespaces and semaphores and so on. For IDC over Xen you do not have this luxury, unless you modify Xen, or you are building over higher-level communication primitives (which perhaps defeats the purpose).

 -- Keir



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