From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqbrv-00026e-JT for qemu-devel@nongnu.org; Thu, 14 Apr 2016 03:39:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqbrs-0005F8-6G for qemu-devel@nongnu.org; Thu, 14 Apr 2016 03:39:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38190) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqbrs-0005F0-0r for qemu-devel@nongnu.org; Thu, 14 Apr 2016 03:39:12 -0400 From: Markus Armbruster References: <1460102035-15972-1-git-send-email-mst@redhat.com> <87twjcvz7o.fsf@dusky.pond.sub.org> <20160409200141-mutt-send-email-mst@redhat.com> <8760voo18x.fsf@dusky.pond.sub.org> <20160411142509-mutt-send-email-mst@redhat.com> <8760vlq3yg.fsf@dusky.pond.sub.org> <20160413173957-mutt-send-email-mst@redhat.com> <87d1ptiiqc.fsf@dusky.pond.sub.org> <20160413205305-mutt-send-email-mst@redhat.com> Date: Thu, 14 Apr 2016 09:39:07 +0200 In-Reply-To: <20160413205305-mutt-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Wed, 13 Apr 2016 20:53:37 +0300") Message-ID: <87r3e8bpwk.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Paolo Bonzini , "Gabriel L . Somlo" , Laszlo Ersek , qemu-devel@nongnu.org, Gerd Hoffmann "Michael S. Tsirkin" writes: > On Wed, Apr 13, 2016 at 06:19:55PM +0200, Markus Armbruster wrote: >> "Michael S. Tsirkin" writes: >> >> > On Wed, Apr 13, 2016 at 10:59:35AM +0200, Markus Armbruster wrote: >> >> If we can protect them without >> >> complicating or breaking stuff, sure, why not. But not at all costs. >> > >> > The stuff we break is precisely the stuff our warnings >> > say might break at any time. So since you believe users >> > might be relied on not to ignore warnings, it should be ok ... >> > >> > As for complicating things - about 5 lines of code are spent >> > on the unsupported/root/ hack. It *is* a hack but >> > contained enough not to worry me too much ... >> >> I'm not worried about the implementation complexity at all. It's the >> user interface complexity. After this patch, we have a non-trivial >> mapping from -fw_cfg name to FW_CFG filename to explain. Whereas now, >> -fw_cfg name *is* the FW_CFG path. > > Only for people who ignore the rules. Most people have a trivial > mapping. Even when most usage falls into the simple cases, you still have to explain all cases. An interface's complexity is a property of the interface, not of its usage.