From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53051) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apa42-0003h5-P0 for qemu-devel@nongnu.org; Mon, 11 Apr 2016 07:31:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1apa3z-0003Iz-KF for qemu-devel@nongnu.org; Mon, 11 Apr 2016 07:31:30 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1apa3z-0003Ic-Ef for qemu-devel@nongnu.org; Mon, 11 Apr 2016 07:31:27 -0400 Date: Mon, 11 Apr 2016 14:31:21 +0300 From: "Michael S. Tsirkin" Message-ID: <20160411142509-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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8760voo18x.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 Mon, Apr 11, 2016 at 01:04:14PM +0200, Markus Armbruster wrote: > My best guess > is you're referring to the part where I challenge mapping > /unsupported/root/FOO to FOO. I find that baroque. I can accept > baroque when I see a reason. That's why I asked for it. "I got ACKs > for it" is not a particular satisfying reason, but I figure you got > another one. Do tell :) The issue I am trying to address is that users can put stuff outside "opt/" without realizing they are violating any rules. I do not think printing a warning is sufficient for this: it is masked by tools too often. Thus, anything outside "opt/" must be forbidden and cause a failure. Gerd and others asked for a way to bypass this "for development" which presumably means they way a quick way to develop guest code interacting with QEMU without changing qemu proper, with the intent to merge support into QEMU a bit later. We could add a special flag for this instead but the mapping is a couple of lines of code, so seems easier, the point is to have "unsupported" there. -- MST