Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread harryxiyou
On Thu, Apr 11, 2013 at 10:59 PM, Daniel P. Berrange wrote: [...] > The question of efficiency is irrelevant in this context. We are > explicitly choosing to prioritize reliability and readability of > the code here. > ACK. -- Thanks Harry Wei -- libvir-list mailing list libvir-list@redhat.com

Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread harryxiyou
On Thu, Apr 11, 2013 at 11:03 PM, Eric Blake wrote: [...] > No need. You are talking about the error path, the one that only hits > on the RARE case of OOM. If we are OOM, we are already hosed - what > does it matter if we take a few extra calls to a few more virCommand*() > functions before fin

Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread Eric Blake
On 04/11/2013 08:48 AM, harryxiyou wrote: > On Thu, Apr 11, 2013 at 10:26 PM, Eric Blake wrote: > > Hi Eric, > > [...] >> Not necessary. virCommand is DESIGNED for streamlined usage, so that it >> is much easier to read how the command is constructed without being >> distracted by error checkin

Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread Daniel P. Berrange
On Thu, Apr 11, 2013 at 10:48:05PM +0800, harryxiyou wrote: > On Thu, Apr 11, 2013 at 10:26 PM, Eric Blake wrote: > > Hi Eric, > > [...] > > Not necessary. virCommand is DESIGNED for streamlined usage, so that it > > is much easier to read how the command is constructed without being > > distra

Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread harryxiyou
On Thu, Apr 11, 2013 at 10:26 PM, Eric Blake wrote: Hi Eric, [...] > Not necessary. virCommand is DESIGNED for streamlined usage, so that it > is much easier to read how the command is constructed without being > distracted by error checking in the caller every step of the way. As a > virComma

Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread Michal Privoznik
On 11.04.2013 15:48, harryxiyou wrote: > On Thu, Apr 11, 2013 at 9:38 PM, Michal Privoznik wrote: > [...] >> Maybe you've pasted wrong code snippet, but the one you've pasted is >> correct. If virCommandRun() fails and returns -1; we return that value >> to the caller. And if the command doesn't f

Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread Eric Blake
On 04/11/2013 07:48 AM, harryxiyou wrote: > On Thu, Apr 11, 2013 at 9:38 PM, Michal Privoznik wrote: > [...] >> Maybe you've pasted wrong code snippet, but the one you've pasted is >> correct. If virCommandRun() fails and returns -1; we return that value >> to the caller. And if the command doesn'

Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread harryxiyou
On Thu, Apr 11, 2013 at 9:38 PM, Michal Privoznik wrote: [...] > Maybe you've pasted wrong code snippet, but the one you've pasted is > correct. If virCommandRun() fails and returns -1; we return that value > to the caller. And if the command doesn't fail, we call > virStorageBackendSheepdogParseN

Re: [libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread Michal Privoznik
On 11.04.2013 15:33, harryxiyou wrote: > Hi all, > > I copy portions of libvirt/src/storage/storage_backend_sheepdog.c > [...] > 125 ret = virCommandRun(cmd, NULL); > 126 if (ret == 0) > 127 ret = virStorageBackendSheepdogParseNodeInfo(pool->def, output); > [...] > > I found virCo

[libvirt] [RFC] virCommandRun return error number

2013-04-11 Thread harryxiyou
Hi all, I copy portions of libvirt/src/storage/storage_backend_sheepdog.c [...] 125 ret = virCommandRun(cmd, NULL); 126 if (ret == 0) 127 ret = virStorageBackendSheepdogParseNodeInfo(pool->def, output); [...] I found virCommandRun may return '-1', which hinds something error happe