Re: [Xen-devel] [PATCH] [qemu] xen_be_init under stubdom

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Kamala Narasimhan writes ("Re: [Xen-devel] [PATCH] [qemu] xen_be_init under 
stubdom"):
> I did call it inconsequential and wouldn't have sent it if it didn't
> happen to be with a one liner that had functional impact that I wanted
> changed :)

What functional impact does it have ?

> > There is nothing wrong with
> > calling qemu_free(0) and IMO in general functions that "goto cleanup"
> > are to be preferred to ones that "return".
> 
> You would rather check for null pointer and then go to cleanup code
> whose sole purpose in this case is to free that pointer and all this
> for free to realize that it has nothing to free and then return back!

Yes.  That avoids having to reason whether there is other stuff that
might need to be freed.  If more code is added later which allocates
something else then the plain "return" may become buggy.

> > Furthermore, even if this patch were good, it's not a bugfix so is not
> > acceptable at this stage of the release.
> 
> No, it does get rid of an issue I encounter.  I was running into data
> corruption as this code path was taken with stubdom in my
> configuration and it was a pain to debug as with these kinds of
> corruption issues the problem showed up elsewhere.

Are you saying that in stubdom, this code path causes your code to
crash ?  That is not the fault of the code path.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel