[libvirt] [PATCH 1/3] vmx: Use the allocator virDomainChrDefNew

[Pavel Hrdina]

On Fri, Oct 21, 2016 at 01:58:42PM -0400, John Ferlan wrote:
> 
> 
> On 10/21/2016 12:01 PM, Pavel Hrdina wrote:
> > On Fri, Oct 21, 2016 at 09:01:42AM -0400, John Ferlan wrote:
> >> Rather than VIR_ALLOC of the virDomainChrDefPtr
> >>
> >> Signed-off-by: John Ferlan <jferlan at redhat.com>
> >> ---
> >>  src/vmx/vmx.c | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/src/vmx/vmx.c b/src/vmx/vmx.c
> >> index fc4347f..f61c4d6 100644
> >> --- a/src/vmx/vmx.c
> >> +++ b/src/vmx/vmx.c
> >> @@ -2758,7 +2758,7 @@ virVMXParseSerial(virVMXContext *ctx, virConfPtr conf, int port,
> >>          return -1;
> >>      }
> >>  
> >> -    if (VIR_ALLOC(*def) < 0)
> >> +    if (!(*def = virDomainChrDefNew(NULL)))
> >>          return -1;
> >>  
> >>      (*def)->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_SERIAL;
> >> @@ -2946,7 +2946,7 @@ virVMXParseParallel(virVMXContext *ctx, virConfPtr conf, int port,
> >>          return -1;
> >>      }
> >>  
> >> -    if (VIR_ALLOC(*def) < 0)
> >> +    if (!(*def = virDomainChrDefNew(NULL)))
> >>          return -1;
> >>  
> >>      (*def)->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_PARALLEL;
> >> -- 
> > 
> > You've missed those two occurrences:
> >     src/conf/domain_conf.c:3876            if (VIR_ALLOC(def->consoles[0]) < 0)
> >     src/conf/domain_conf.c:3891        if (VIR_ALLOC(chr) < 0)
> > 
> 
> Thanks - I added them... I tried scouring all virDomainChrDef[Ptr] - I
> probably just had the overwhelming power of assumption that
> domain_conf.c would have used virAllocChrDefNew properly. The *-aa-*
> were certainly one of those environments in the 5% from my cover...
> 
> Those will have to be (NULL) calls though which I would think be correct
> since they're going to be implicitly added and they wouldn't be needing
> a TLS backend setup.

Oh, that's right, because this is just a copy of the first serial char device
and it is not actually used to create a command line.

> Not clear if there was an implicit ACK here or not, so I'll wait to push
> since it's not ultra critical to get this in.

So yes, it's an ACK.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20161021/fc853cf4/attachment-0001.sig>