[libvirt] [PATCH 0/5] macvtap support for Qemu/KVM VMs via libvirt
Daniel Veillard
veillard at redhat.com
Thu Feb 11 11:32:08 UTC 2010
On Tue, Feb 09, 2010 at 06:40:12PM +0000, Daniel P. Berrange wrote:
> On Tue, Feb 09, 2010 at 10:21:20AM -0500, Stefan Berger wrote:
> > Daniel,
> >
> > some of this code doesn't build anymore due to the recent changes with
> > the conn parameter being removed.
> > Do you want me to re-submit?
>
> Not at this time - there are a whole lot more patches I'm working on to
> remove 'conn' from many other places which would just break your code
> again. We can do any neccessary fixup to these macvtap patches at time
> of commit.
>
> > I actually liked the conn parameter for error reporting and handling in
> > the return path. Any function
> > where the conn parameter was needed, I anticipated a simple return code
> > for success and failure with the
> > error already attached to the 'conn' parameter via one of the error
> > reporting functions. Other functions
> > where the conn parameter was not passed, the return value was anticipated
> > to have an 'errno meaning'. Now
> > that meaning seems lost. I am wondering whether I can still leave the conn
> > parameter as an ATTRIBUTE_UNUSED
> > for those functions where I only anticipate a success/failure return and
> > error already being reported
> > via a function?
>
> The main problem with the 'conn' parameter is that there are a huge
> set of circumstances in which it will be 'NULL' and we've had too
> many bugs where code assumed it would always be non-NULL. By removing
> the conn parameter (nearly) everywhere in the internal APIs we can
> get rid of this source of bugs.
>
> We've not really enumerated it anywhere, but as a general rule helper
> functions should set the libvirt full error. I'd like to see the returning
> of 'errno' reduced to be an exception, just used in places where the caller
> needs to handle & ignore the potential errno.
>
> Again don't worry about updating these patches of yours yet - this error
> reporting / conn cleanup is a big ongoing project....
I think the cleanup has been pushed to git now, so maybe it's worth
rebasing, if you could also look at the my few comments about the
patches in the process :-)
thanks !
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
More information about the libvir-list
mailing list