From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzNjW-0004lg-Ob for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:18:19 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzNjT-0000aF-Dg for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:18:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55361) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzNjT-0000a9-88 for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:18:15 -0400 Message-ID: <556C3F71.3090801@redhat.com> Date: Mon, 01 Jun 2015 13:18:09 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1430320913-20737-1-git-send-email-somlo@cmu.edu> <1430320913-20737-5-git-send-email-somlo@cmu.edu> <20150531181048.GC5268@redhat.com> <556C046B.9070704@redhat.com> <20150601092645-mutt-send-email-mst@redhat.com> <556C1F63.1090605@redhat.com> <20150601121908-mutt-send-email-mst@redhat.com> <556C3757.7080603@redhat.com> <20150601124604-mutt-send-email-mst@redhat.com> <556C390A.7090706@redhat.com> <20150601130002-mutt-send-email-mst@redhat.com> In-Reply-To: <20150601130002-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH V4 4/4] fw_cfg: insert fw_cfg file blobs via qemu cmdline List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: matt.fleming@intel.com, "Gabriel L. Somlo" , qemu-devel@nongnu.org, gsomlo@gmail.com, kraxel@redhat.com, Laszlo Ersek 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. > >=20 > > What is for playing games? What is the feature useful for, except fo= r > > developers. >=20 > 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/