public inbox for passt-dev@passt.top
 help / color / mirror / code / Atom feed
From: Laine Stump <laine@redhat.com>
To: Libvirt <libvir-list@redhat.com>
Cc: sbrivio@redhat.com, passt-dev@passt.top, "Ján Tomko" <jtomko@redhat.com>
Subject: Re: [libvirt PATCH 3/9] conf: put interface <backend> parsing/formatting separate functions
Date: Mon, 9 Jan 2023 02:04:19 -0500	[thread overview]
Message-ID: <0c6191d2-8972-b630-d1ae-3ecebcf7922e@redhat.com> (raw)
In-Reply-To: <Y7u4irUL3IlQR79q@fedora>

On 1/9/23 1:47 AM, Ján Tomko wrote:
> On a Sunday in 2023, Laine Stump wrote:
>> In preparation for adding more stuff to <backend>.
>>
>> Signed-off-by: Laine Stump <laine@redhat.com>
>> ---
>>
>> I wanted virDomainNetBackendParseXML to simply take a
>> virDomainNetBackend*, but there is a test case specifically checking
>> to be sure that backend/vhost isn't parsed if the interface isn't
>> virtio. Silently Ignoring+stripping this during parse is arguably the
>> wrong thing to do - either we should log an error on validation, or we
>> should just leave it in (it's only ever used if the interface is
>> virtio), but that's a problem for another day.
>>
>> (Opinions on the proper thing to do are welcome - since it's currently
>> always stripped out on parse, I *think* I could begin checking for it
>> during validation - there is no way that old code could leave the
>> backend/vhost for a non-virtio interface in any domain xml written to
>> disk.
> 
> This seems like the right thing to do.
> 
>> Alternately would could just allow it to be parsed and
>> faithfully format it even when the interface isn't virtio, and not log
>> any error.)
>>
>> src/conf/domain_conf.c | 57 +++++++++++++++++++++++++++++++-----------
>> 1 file changed, 42 insertions(+), 15 deletions(-)
>>
>> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
>> index 30b0cef131..9502f2ebab 100644
>> --- a/src/conf/domain_conf.c
>> +++ b/src/conf/domain_conf.c
>> @@ -8970,6 +8970,26 @@ virDomainNetDefParseXMLDriver(virDomainNetDef 
>> *def,
>> }
>>
>>
>> +static int
>> +virDomainNetBackendParseXML(xmlNodePtr node,
>> +                            virDomainNetDef *def)
>> +{
>> +    g_autofree char *tap = virXMLPropString(node, "tap");
>> +    g_autofree char *vhost = virXMLPropString(node, "vhost");
>> +
>> +    if (tap)
>> +        def->backend.tap = virFileSanitizePath(tap);
>> +
>> +    if (vhost &&
>> +        def->type != VIR_DOMAIN_NET_TYPE_HOSTDEV &&
>> +        virDomainNetIsVirtioModel(def)) {
>> +        def->backend.vhost = virFileSanitizePath(vhost);
>> +    }
>> +
>> +    return 0;
>> +}
>> +
>> +
>> static int
>> virDomainNetDefParseXMLRequireSource(virDomainNetDef *def,
>>                                      xmlNodePtr source_node)
>> @@ -9016,6 +9036,7 @@ virDomainNetDefParseXML(virDomainXMLOption *xmlopt,
>>     xmlNodePtr mac_node = NULL;
>>     xmlNodePtr target_node = NULL;
>>     xmlNodePtr coalesce_node = NULL;
>> +    xmlNodePtr backend_node = NULL;
>>     VIR_XPATH_NODE_AUTORESTORE(ctxt)
>>     int rv;
>>     g_autofree char *macaddr = NULL;
> 
> src/conf/domain_conf.c:9220:22: error: unused variable 'tap' 
> [-Werror,-Wunused-variable]
>      g_autofree char *tap = NULL;
>                       ^
> 1 error generated.

Yeah, I just found that when I looked at the results of gitlab CI (it 
isn't found by gcc in Fedora 37 :-/). I fixed that as well as 
eliminating a leak in the new function virDomainNetPortForwardFree() (I 
had forgotten to free the pf->range after freeing all the ranges that it 
pointed to).

> 
>> @@ -9319,9 +9340,6 @@ virDomainNetDefParseXML(virDomainXMLOption *xmlopt,
>>         (virNetDevVlanParse(vlan_node, ctxt, &def->vlan) < 0))
>>         return NULL;
>>
>> -    if ((tap = virXPathString("string(./backend/@tap)", ctxt)))
>> -        def->backend.tap = virFileSanitizePath(tap);
>> -
>>     if ((mac_node = virXPathNode("./mac", ctxt))) {
>>         if ((macaddr = virXMLPropString(mac_node, "address"))) {
>>             if (virMacAddrParse((const char *)macaddr, &def->mac) < 0) {
> 
> With the unused variable removed:
> 
> Reviewed-by: Ján Tomko <jtomko@redhat.com>
> 
> Jano


  reply	other threads:[~2023-01-09  7:04 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-09  4:11 [libvirt PATCH 0/9] Support libvirt-managed QEMU domain <interface> backed by a passt process Laine Stump
2023-01-09  4:11 ` [libvirt PATCH 1/9] conf: rename virDomainNetBackend* to virDomainNetDriver* Laine Stump
2023-01-09  5:40   ` Ján Tomko
2023-01-09  4:11 ` [libvirt PATCH 2/9] conf: move anonymous backend struct from virDomainNetDef into its own struct Laine Stump
2023-01-09  5:41   ` Ján Tomko
2023-01-09  4:11 ` [libvirt PATCH 3/9] conf: put interface <backend> parsing/formatting separate functions Laine Stump
2023-01-09  5:47   ` Ján Tomko
2023-01-09  7:04     ` Laine Stump [this message]
2023-01-09  4:11 ` [libvirt PATCH 4/9] conf: add passt XML additions to schema Laine Stump
2023-01-09  5:48   ` Ján Tomko
2023-01-11 18:33   ` Daniel P. Berrangé
2023-01-12 14:45     ` Laine Stump
2023-01-12 17:28       ` Stefano Brivio
2023-01-12 18:12       ` Jiri Denemark
2023-01-09  4:11 ` [libvirt PATCH 5/9] conf: parse/format passt-related XML additions Laine Stump
2023-01-09  6:18   ` Ján Tomko
2023-01-09  4:11 ` [libvirt PATCH 6/9] qemu: new capability QEMU_CAPS_NETDEV_STREAM Laine Stump
2023-01-09  6:20   ` Ján Tomko
2023-01-09  4:11 ` [libvirt PATCH 7/9] qemu: add passtStateDir to qemu driver config Laine Stump
2023-01-09  6:23   ` Ján Tomko
2023-01-09 14:02     ` Laine Stump
2023-01-09  4:11 ` [libvirt PATCH 8/9] qemu: hook up passt config to qemu domains Laine Stump
2023-01-09  6:31   ` Ján Tomko
2023-01-09 14:14     ` Laine Stump
2023-01-09 14:51       ` Ján Tomko
2023-01-09 16:05         ` Laine Stump
2023-01-09  4:11 ` [libvirt PATCH 9/9] specfile: require passt for the build if fedora >= 36 or rhel >= 9 Laine Stump
2023-01-09  6:32   ` Ján Tomko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c6191d2-8972-b630-d1ae-3ecebcf7922e@redhat.com \
    --to=laine@redhat.com \
    --cc=jtomko@redhat.com \
    --cc=libvir-list@redhat.com \
    --cc=passt-dev@passt.top \
    --cc=sbrivio@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://passt.top/passt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for IMAP folder(s).