It's a bit hard to maintain the original intention with just
documentation. Couldn't we require that --without-default-devices always
be accompanied by --with-devices?
Maybe, but why would it be bad to just patch the default .mak file?
And more to the point of Peter's
question, couldn't we just leave the defaults off unconditionally when
--without-default-devices is passed without --with-devices?
No, for example RHEL adds a lot of devices and is perfectly usable without --nodefaults, but we still use --without-default-devices because we want any new config to be opt in, unless it's always needed.
The coupling of -nodefaults with --without-default-devices is a bit
redundant. If we're choosing to not build some devices, then the QEMU
binary should already know that.
--without-default-devices is not about choosing to not build some devices; it is about making non-selected devices opt-in rather than opt-out.
Paolo
Just to be clear, -nodefaults by itself still makes sense because we can
have a simple command line for those using QEMU directly while allowing
the management layer to fine tune the devices.
In the long run, I think we need to add some configure option that gives
us pure allnoconfig so we can have that in the CI and catch these CONFIG
issues before merging. There's no reason to merge a new CONFIG if it
will then be impossible to turn it off.