From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54976) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agYPA-00081A-Q7 for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:56:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1agYP7-00023N-KB for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:56:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56294) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1agYP7-00023B-Dr for qemu-devel@nongnu.org; Thu, 17 Mar 2016 09:55:57 -0400 References: <1458053080-29170-1-git-send-email-mst@redhat.com> <87fuvpv2jv.fsf@blackfin.pond.sub.org> <20160317143531-mutt-send-email-mst@redhat.com> <56EAB17A.1000400@redhat.com> <20160317153528-mutt-send-email-mst@redhat.com> From: Paolo Bonzini Message-ID: <56EAB768.2000406@redhat.com> Date: Thu, 17 Mar 2016 14:55:52 +0100 MIME-Version: 1.0 In-Reply-To: <20160317153528-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/ List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Laszlo Ersek , "Gabriel L. Somlo" , Gerd Hoffmann , Markus Armbruster , qemu-devel@nongnu.org On 17/03/2016 14:49, Michael S. Tsirkin wrote: >> On 17/03/2016 14:13, Michael S. Tsirkin wrote: >>> >>> QEMU command line: >>> A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get conflicts >>> with QEMU hardware >> >> Alternative: no need to prepend usr/, I think. >=20 > I personally dislike telling user "do X". I don't see a reason not to b= e > friendly and do X. The rare case where users do not want X can be > easily enabled. I wouldn't include usr/ at all in the paths. The RFQDN recommendation is enough to avoid clashes with etc/ and opt/. >>> B. -fw-cfg org.qemu/unsupported/XXX as a hack, removes >>> org.qemu/unsupported/ and leaves just XXX, >>> for people who want to break^?^?^?^?^?debug QEMU hardware >> >> Alternative: fail on: >> >> - a blacklist of etc/* files including etc/system-states, >> etc/smbios/smbios-tables, etc/smbios/smbios-anchor, >> etc/reserved-memory-end, etc/pvpanic-port, etc/e820, and possibly >> etc/boot-menu-wait >=20 > We can not predict the future. Future firmware will look for > files under etc/mst. Users using this firmware with > current QEMU will get a nasty surprise where it previously > worked. >=20 > Besides, it is way easier to maintain and understand a simple rule than > a blacklist. The reason for the blacklist is that these are files owned by QEMU but traditionally under etc/. The error can be simply "fw_cfg file %s is provided by QEMU". If a file is added in the future that is owned by QEMU, it will be under org.qemu/* so the blacklist will not grow. >> Likewise SeaBIOS would switch from etc/ to an org.seabios/ prefix (for >> stuff usable from both Coreboot and QEMU, e.g. >> org.seabios/bootsplash.bmp) or org.qemu/ (for stuff that is specific t= o >> QEMU). >> >> Files that could be moved from etc/ to org.qemu/ correspond to the one= s >> that are blacklisted in (B), e.g. etc/system-states -> >> org.qemu/system-states. >=20 > I am not sure about moving things into usr/org.qemu. > These are system files, not user-provided ones. > But we can argue about future plans down the road. Does it make more sense if it's just org.qemu, not usr/org.qemu? Thanks, Paolo