From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ar5qP-0002ld-M1 for qemu-devel@nongnu.org; Fri, 15 Apr 2016 11:39:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ar5qK-0003Jb-MS for qemu-devel@nongnu.org; Fri, 15 Apr 2016 11:39:41 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ar5qK-0003JV-I0 for qemu-devel@nongnu.org; Fri, 15 Apr 2016 11:39:36 -0400 From: Markus Armbruster References: <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> <20160414111049-mutt-send-email-mst@redhat.com> <87y48g8m3z.fsf@dusky.pond.sub.org> <20160414150434-mutt-send-email-mst@redhat.com> Date: Fri, 15 Apr 2016 17:39:33 +0200 In-Reply-To: <20160414150434-mutt-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Thu, 14 Apr 2016 15:13:07 +0300") Message-ID: <87r3e6naoa.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 [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.