[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 1/5] report OOMError in virDomainDiskInsert()



On Tue, Mar 15, 2011 at 03:38:50PM -0600, Eric Blake wrote:
> On 03/02/2011 06:09 PM, KAMEZAWA Hiroyuki wrote:
> >>From b92569080a25bf0029d637327a87372bff071fae Mon Sep 17 00:00:00 2001
> > From: KAMEZAWA Hiroyuki <kamezawa hiroyu jp fujitsu com>
> > Date: Thu, 3 Mar 2011 09:20:36 +0900
> > Subject: [PATCH 1/5] report OOMError in virDomainDiskInsert()
> > 
> > Now, virDomainDiskInsert() returns -1 at memory allocation
> > failure but it should call virReportOOMError() by itself.
> > 
> > Signed-off-by: KAMEZAWA Hiroyuki <kamezawa hiroyu jp fujitsu com>
> > ---
> >  src/conf/domain_conf.c |    4 +++-
> >  src/xen/xm_internal.c  |    4 +---
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> This patch looks accurate, but lacks justification (why can't all
> callers continue to call virReportOOMError() on failure)?  I'm not sure

Sure they can, but on the premise that they are sure there is an OOM
happens. The semantics of virDomainDiskInsert is not clear here, returns
-1 just means a failure but not an OOM. What if virDomainDiskInsert
fails for other reasons, is it still correct for the caller to call
virReportOOMError()?

> whether to apply it without knowing why it is needed, as it just looks
> like code motion churn in isolation.
> 
> -- 
> Eric Blake   eblake redhat com    +1-801-349-2682
> Libvirt virtualization library http://libvirt.org
> 

-- 
Thanks,
Hu Tao


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]