On Wed, Sep 14, 2011 at 01:42:22PM +0200, Peter Krempa wrote:
> Commit 498d783387389bfd74437bf84374583f5a3d3bf6 cleans up some of
> virtual file names for parsing strings in memory. This patch cleans up
> (hopefuly) the rest forgotten by the first patch.
> ---
> src/conf/domain_conf.c | 4 ++--
> src/conf/interface_conf.c | 2 +-
> src/conf/network_conf.c | 2 +-
> src/conf/node_device_conf.c | 2 +-
> src/conf/nwfilter_conf.c | 2 +-
> src/conf/secret_conf.c | 2 +-
> src/conf/storage_conf.c | 6 +++---
> src/cpu/cpu.c | 4 ++--
> src/esx/esx_vi.c | 2 +-
> src/qemu/qemu_migration.c | 2 +-
> 10 files changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index 11755fe..886aa53 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -5739,7 +5739,7 @@ virDomainDeviceDefPtr virDomainDeviceDefParse(virCapsPtr caps,
> xmlXPathContextPtr ctxt = NULL;
> virDomainDeviceDefPtr dev = NULL;
>
> - if (!(xml = virXMLParseStringCtxt(xmlStr, "device.xml", &ctxt))) {
> + if (!(xml = virXMLParseStringCtxt(xmlStr, _("(device definition)"), &ctxt))) {
Considering the previous patch this one makes sense, but I realize
that the string passed is supposed to be an URI, doesn't have to be
absolute but the principle of that argument passed to the parser, beside
giving a name for the 'entity' (basically a file in XML terminology)
is used to resolve URI-References done from within the XML content.
Since we don't use any DTD, this should not affect parsing, but users
might be tempted to add this for fun or validation, and that would not
be wrong. Simply replacing the spaces by underscore in the string would
be sufficient to make them correct URIs (I doubt %escape of the space
would be any nicer for the users...)
So in one hand, yes this makes sense, but I wonder if we shouldn't
clean this up ...
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