From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1argcZ-0007EG-15 for qemu-devel@nongnu.org; Sun, 17 Apr 2016 02:55:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1argcV-0007UI-Py for qemu-devel@nongnu.org; Sun, 17 Apr 2016 02:55:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:51065) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1argcV-0007UE-Kx for qemu-devel@nongnu.org; Sun, 17 Apr 2016 02:55:47 -0400 Date: Sun, 17 Apr 2016 09:55:42 +0300 From: "Michael S. Tsirkin" Message-ID: <20160417095450-mutt-send-email-mst@redhat.com> References: <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> <20160414111049-mutt-send-email-mst@redhat.com> <87y48g8m3z.fsf@dusky.pond.sub.org> <20160414150434-mutt-send-email-mst@redhat.com> <87r3e6naoa.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r3e6naoa.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 Fri, Apr 15, 2016 at 05:39:33PM +0200, Markus Armbruster wrote: > [Context restored] > > "Michael S. Tsirkin" writes: > > > On Thu, Apr 14, 2016 at 01:29:20PM +0200, Markus Armbruster wrote: > >> The next use case to consider is a user picking a new name for a new > >> interface between host and guest. I find the idea that such a user > >> won't notice warnings farfetched. But let's assume such users exist. > >> We're talking about someone who strays out of /opt out of willfulness or > >> ignorance *and* can't be bothered to read warnings, and because of that > >> we reject his usage outright to drive home the point. > >> > >> What good is that going to do? What are the chances this will make such > >> a user actually read the docs, pick an appropriate RFQDN and stick to > >> /opt/RFQDN/? I think they're remote. Multipy it by the probability of > >> this case even happening, and the result is even more remote. > > > > Enforce a sane policy. It's too easy to misconfigure qemu as it is. > > We don't need more knobs that can break guests. > > While that's a valid point, it's not an answer to the question I asked. > > My point is that anyone violating the rules despite the warning before > your patch is highly likely to violate them just as badly afterwards. > Therefore, the probability of your patch being of any use there is > 1 - highly likely. My point is that's not so because not all users see our warnings. They will notice that they are passing "unsupported" in the path. -- MST