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

On 04/11/2013 08:48 AM, harryxiyou 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 finally reporting the error to the user? All that matters is that we are hosed gracefully (ie. that we DO report the error, instead of crashing). On the common case, virCommandNew*() never fails, so every step of the way is important and there is nothing that can be shaved. It boils down to whether you check for NULL at every call site (a maintenance burden) or inside every virCommand*() API - either way, a NULL check has to be done to remain robust, but we intentionally chose the design that results in the fewest lines of code. There is NOTHING wrong here. Quit trying to make a bug out of something that's working. One more point: libvirt is generally not the bottleneck. Remember, libvirt is the management, the thing that kicks off the long-running tasks. But the long running tasks are separate processes. Libvirt itself is not doing the long-running task. Therefore, shaving a few instructions off of libvirt is generally going to have a negligible effect on the overall performance of your usage of the virt stack. Focus on features, not micro-optimizations, unless you can first post benchmarks proving that libvirt is indeed the cause of a bottleneck you are trying to optimize. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org