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.hir...@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.hir...@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 ebl...@redhat.com +1-801-349-2682 > Libvirt virtualization library http://libvirt.org > -- Thanks, Hu Tao -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
