Re: [libvirt] [PATCH v2 9/9] cpu-baseline command for virsh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Feb 12, 2010 at 11:05:54AM +0000, Daniel P. Berrange wrote:
> On Thu, Feb 11, 2010 at 09:37:58PM +0100, Daniel Veillard wrote:
> > On Thu, Feb 11, 2010 at 08:49:54PM +0100, Jiri Denemark wrote:
> > > > > +    if (virFileReadAll(from, VIRSH_MAX_XML_FILE, &buffer) < 0)
> > > > > +        return FALSE;
> > > > > +
> > > > > +    p = buffer;
> > > > > +    while ((p = strstr(p, "<cpu>"))) {
> > > > > +        list = vshRealloc(ctl, list, sizeof(char *) * (count + 1));
> > > > > +        list[count++] = p;
> > > > > +
> > > > > +        if ((p = strstr(p, "</cpu>"))) {
> > > > > +            p += strlen("</cpu>");
> > > > > +            if (*p != '\0') {
> > > > > +                *p = '\0';
> > > > > +                p++;
> > > > > +            }
> > > > > +        }
> > > > > +    }
> > > > 
> > > >   Aye aye aye ...  I understand what you're trying to do but I think
> > > > this is a bit weird  ... I think we should be able to come with an
> > > > alternative, cleaner based on parsing the content as an XML well
> > > > balanced fragment and then reserialize all cpu elements found.
> > > >   Your scheme would explode for example if we tried to add a <cpu>
> > > > element as one possible child of <cpu> or if we added attributes to
> > > > <cpu>, it's too fragile. I can think the other parts can be commited
> > > > independantly anyway.
> > > 
> > > Yeah, it's ugly but I wanted to avoid the complexity of parsing XML and
> > > formating back to a string. And I still don't think it is a good idea. Maybe I
> > 
> >   Not that hard. The harder is to get libvirt to accept something like a
> > concatenation
> > 
> > ----------------
> > <cpu>
> >   ...
> > </cpu>
> > <cpu>
> >   ...
> > </cpu>
> > ----------------
> > 
> > But I know how to do it (nut never pretend it's XML :-)
> 
> Isn't there anyway to get the XML parser to stop processing input once it
> has parsed one complete document, without consuming the rest of the data
> in the file. eg

  No,

  http://www.w3.org/TR/REC-xml/#NT-document

  [1]       document       ::=       prolog  element  Misc*

  Misc* means the XML parser has to continue feeding it's input
until being told that's over. XML is not suitable for concatenation

> > <cpu>
> >   ...
> > </cpu>
> 
> Make it stop here ^^^
> 
> Then, invoke it again to parse the next document in the file
> 
> > <cpu>
> >   ...
> > </cpu>
> 
> And so on.... 

  there is a workaround, parsing as a well balanced chunk,
  http://xmlsoft.org/html/libxml-parser.html#xmlParseBalancedChunkMemory

I will provide a revised version of patch 9 once the 8 others patches
are applied.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel@xxxxxxxxxxxx  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]