From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: [PATCH 3 of 7] Make suspend return 1 when a domain is resumed Date: Fri, 19 Jan 2007 17:09:23 +0000 Message-ID: References: <20070119163651.GA11597@xanadu.kublai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070119163651.GA11597@xanadu.kublai.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Brendan Cully , Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 19/1/07 16:36, "Brendan Cully" wrote: > sorry, that was a bad comment. I'd been using "resume" to mean > suspend-cancel and "reconnect" to mean run in a new domain. This patch > is the backwards compatible version (it sets EAX to 1 in xc_linux_save > rather than xc_linux_restore). Oh, I see. Makes sense. > I poked around the elfnote route for advertising kernel features to > xend, and I have a feeling someone else should be designing the API > for that - I only want very little out of it and would probably be > shortsighted. For instance, it wasn't clear to me whether it'd be > better to have an xc function that returns almost raw elfnotes (an > array of (type, length, contents)) or only parsed, named elfnotes, or > only features. The xenctrl function that pulls out the elfnote info is going to need to know about specific elfnotes, the type of contents, and have a sensible strategy for stringifying them. I suggest (type, contents) pairs where type is the elfnote type name, and contents is content-specific string. There are lots of elfnotes so you only need worry about the elfnote you care about (your new one) -- all I want is a framework where we can extract more elfnotes as and when we need to. -- Keir