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(a)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(a)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)