On Tue, Apr 18, 2023 at 03:43:41PM +0200, 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@xxxxxxxxxx> > > > > --- > > > > 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@xxxxxxxxxx> > > > > 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) */ Yeah, not quite clear-cut, but XML_ERROR seems more suitable for a situation where the XML is structurally incorrect (e.g. <disk> nested inside <interface> or something like that) as opposed to simply trying to enable a set of features that don't work well together. I'll stick with CONFIG_UNSUPPORTED. -- Andrea Bolognani / Red Hat / Virtualization