From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Trivial patch to fix logging level output by XendCheckpoint.py Date: Mon, 20 Nov 2006 16:34:22 -0600 Message-ID: <45622D6E.9020607@us.ibm.com> References: <342BAC0A5467384983B586A6B0B3767104190365@EXNA.corp.stratus.com> <20061120215600.GE15703@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20061120215600.GE15703@redhat.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: "Daniel P. Berrange" Cc: xen-devel , Christian Limpach List-Id: xen-devel@lists.xenproject.org Daniel P. Berrange wrote: > On Mon, Nov 20, 2006 at 04:34:25PM -0500, Graham, Simon wrote: >> Signed-off by: Simon Graham > And even more importantly, once we get the error reporting patches integrated > into libxc, having the xc_linux_save/restore calls made by XenD directly > would ensure we get reliable error handling for save/restore operations. It used to work that way. xc_linux_save/restore were factored out of Xend late in the 3.0 dev process. I believe the idea was that they should be executed with lower privileges (which is why they take file descriptors as command line arguments instead of just calling xc_interface_open() like you would expect). I believe it was Christian who was driving this. Perhaps he has a few more details? Regards, Anthony Liguori > So, is there any good reason for xc_save & xc_restore to exist as separate > processes - it just seems like a huge complication to me, increasing > fragility of the system & reducing the quality of error reporting we can > get > > Regards, > Dan.