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 11:59:08 -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 18:03:09 +0000
Envelope-to: xen+James.Bulpin@xxxxxxxxxxxx
In-reply-to: <1ad6b47f0eb08a9a0218b83fb5f43865@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> <1ad6b47f0eb08a9a0218b83fb5f43865@xxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
Keir Fraser wrote:

A reasonable interface to user-space, but what about when one endpoint is inside the kernel? I'm also concerned that SysV IPC is usually used between mutually trusting parties -- this is *not* necessarily the case between management services and managed domains. We need e.g., control over event-channel masking to be able to limit management resources consumed by overzealous or malicious guests.

I'm not suggesting we use the SysV interfaces, just the mechanisms (named shared memory, message queues, semaphores). As primatives, this seems like a good place to start. As interfaces, I agree that SysV is not the way to go :-)

The persistent store protocol could be implemented on top of these mechanisms. Any primatives would also have to be shared between kernel and userspace (either through common header files or perhaps a kernel interface to userspace for these mechanisms).

It's really just about generalizing what's already being used.

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>