From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqcNO-0001Ce-4F for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:11:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aqcNK-0005km-3u for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:11:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aqcNJ-0005kT-U3 for qemu-devel@nongnu.org; Thu, 14 Apr 2016 04:11:42 -0400 Date: Thu, 14 Apr 2016 11:11:37 +0300 From: "Michael S. Tsirkin" Message-ID: <20160414111049-mutt-send-email-mst@redhat.com> 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> <87r3e8bpwk.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r3e8bpwk.fsf@dusky.pond.sub.org> Subject: Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: Paolo Bonzini , "Gabriel L . Somlo" , Laszlo Ersek , qemu-devel@nongnu.org, Gerd Hoffmann On Thu, Apr 14, 2016 at 09:39:07AM +0200, Markus Armbruster wrote: > "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. I think I disagree. Make simple things simple and complex things possible is the rule for a good interface. -- MST