[libvirt PATCH] conf: Restrict use of <portForward> to the passt backend

[Laine Stump]

On 4/18/23 9:43 AM, Ján Tomko wrote:
> On a Tuesday in 2023, Andrea Bolognani wrote:
>> On Tue, Apr 18, 2023 at 03:19:45PM +0200, Ján Tomko wrote:
>>> On a Tuesday in 2023, Andrea Bolognani wrote:
>>> > That's already the case in practice, but it's a better
>>> > experience for the user if we reject this configuration
>>> > outright instead of silently ignoring part of it.
>>> >
>>> > Signed-off-by: Andrea Bolognani <abologna at redhat.com>
>>> > ---
>>> > src/conf/domain_validate.c                    |  9 +++++++++
>>> > ...t-user-slirp-portforward.x86_64-latest.err |  1 +
>>> > .../net-user-slirp-portforward.xml            | 20 +++++++++++++++++++
>>> > tests/qemuxml2argvtest.c                      |  1 +
>>> > 4 files changed, 31 insertions(+)
>>> > create mode 100644 
>>> tests/qemuxml2argvdata/net-user-slirp-portforward.x86_64-latest.err
>>> > create mode 100644 
>>> tests/qemuxml2argvdata/net-user-slirp-portforward.xml
>>>
>>> Reviewed-by: Ján Tomko <jtomko at redhat.com>
>>
>> Thanks for the review!
>>
>> Right before pushing, I realized that VIR_ERR_INTERNAL_ERROR is
>> probably not the best fit for this scenario. Are you okay with me
>> squashing in the changes below?
>>
> 
> Yes.
> 
>      VIR_ERR_CONFIG_UNSUPPORTED = 67,    /* unsupported configuration
>                                             construct (Since: 0.7.3) */
> 
> We also use VIR_ERR_XML_ERROR in similar cases,
> but I'm not sure whether it's more fitting, given its description:
> 
>      VIR_ERR_XML_ERROR = 27,             /* an XML description is not well
>                                             formed or broken (Since: 
> 0.1.1) */

While I think we probably have too many different error categories (even 
though often *none* of them is exactly right for a given circumstance), 
in this case CONFIG_UNSUPPORTED is better, since (IMO) XML_ERROR should 
only be used for something that is *never* valid under any cirsumstance 
(I guess that could also be interpreted in many ways, though)

BTW, an alternate method of fixing this problem would have been to add 
<portForward> support to the slirp code (which is actually item 406 on 
my personal todo list :-P)