Re: [Qemu-devel] [PATCH V4 4/4] fw_cfg: insert fw_cfg file blobs via qemu cmdline

[Paolo Bonzini]

On 01/06/2015 13:00, Michael S. Tsirkin wrote:
> > > If it's just for playing games, add a configure
> > > switch to enable it, and disable by default.
> > > Don't set traps for users.
> > 
> > What is for playing games?  What is the feature useful for, except for
> > developers.
> 
> OK so if it's a dveloper feature, I think a config flag
> to hide it from users is a good idea?

No, please, no antifeatures.

A config flag just means bitrot.  We should _remove_ them (candidates:
--enable-debug, --enable-virtfs, --enable-fdt,
--enable-{linux,bsd}-user, --enable-guest-base, --enable-pie,
--enable-coroutine-pool, --enable-gcov, --enable-quorum, --enable-vhdx,
--enable-vhost-net, --enable-sparse), not add more.

Pretty much the only justification for a --enable-* configure option is
"I don't want my binary to have a dependency on an external library".
More often than not, any other justification probably boils down to a
wrong assumption such as:

- another option is not powerful enough (e.g. --target-list doesn't
support wildcards, hence --disable-system, --disable-users, etc.)

- QEMU's configure wants to do something different from autoconf, the
outcome invariably being bug reports (e.g. stripping debug info by
default, and for a long time falling back to -O0 if you asked not to do
that)

- reviewers didn't ask themselves if other knobs already covered this
(--enable-vhdx)

- people are worried on breaking weird platforms, but you won't ever
know if it breaks unless you dare doing the change (so we have to
maintain old code: --enable-pie)

- we don't want mandatory build-time dependencies that everyone has on
their system anyway (--enable-docs)

- no one really understands what the option does (--disable-guest-base)

- sometimes reasoning about attack surface applies (--disable-kvm), but
then one wonders why we still have no --disable-tcg

- concerns about performance that should have been redirected to
/dev/null or funroll-loops.org [1]

We've already wasted more bytes in this discussion, than would be ever
wasted by a conflict in fw_cfg names.

Paolo

[1] Now at http://fun.irq.dk/funroll-loops.org/