From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzNlD-0005y5-DE for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:20:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YzNlA-0000tZ-59 for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:20:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YzNl9-0000tT-W4 for qemu-devel@nongnu.org; Mon, 01 Jun 2015 07:20:00 -0400 Message-ID: <556C3FDA.509@redhat.com> Date: Mon, 01 Jun 2015 13:19:54 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1430320913-20737-1-git-send-email-somlo@cmu.edu> <1430320913-20737-5-git-send-email-somlo@cmu.edu> <20150531181048.GC5268@redhat.com> <556C046B.9070704@redhat.com> <20150601092645-mutt-send-email-mst@redhat.com> <556C1F63.1090605@redhat.com> <20150601121908-mutt-send-email-mst@redhat.com> <556C3576.8020507@redhat.com> <20150601123957-mutt-send-email-mst@redhat.com> In-Reply-To: <20150601123957-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V4 4/4] fw_cfg: insert fw_cfg file blobs via qemu cmdline List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: matt.fleming@intel.com, "Gabriel L. Somlo" , qemu-devel@nongnu.org, gsomlo@gmail.com, kraxel@redhat.com, Paolo Bonzini On 06/01/15 12:42, Michael S. Tsirkin wrote: > On Mon, Jun 01, 2015 at 12:35:34PM +0200, Laszlo Ersek wrote: >> On 06/01/15 12:23, Michael S. Tsirkin wrote: >>> On Mon, Jun 01, 2015 at 11:01:23AM +0200, Paolo Bonzini wrote: >>>> >>>> >>>> On 01/06/2015 09:28, Michael S. Tsirkin wrote: >>>>>> I don't feel overly strongly about it; just "mechanism, not policy" >>>>>> looks like a good tradition (well, good excuse anyway). >>>>> >>>>> Most users never see warnings. We ship it, we support it. >>>>> If we don't want to support it, let's not ship it. >>>> >>>> Then we should rm -rf half of QEMU. :) >>>> >>>> Seriously, I agree wholeheartedly with not baking policy into QEMU. A >>>> lot of QEMU command-line hacking really is just a shortcut to avoid >>>> continuous recompilation. I don't think it's reasonable to expect that >>>> it constitutes a stable API. >>>> >>>> Paolo >>> >>> Still, reserving part of the namespace for QEMU internal use >>> is *not* policy, it's just good engineering. >>> >>> How about we forbid adding files under "etc/" ? >>> >>> That would be enough to avoid conflicts. >> >> Some of the current fw_cfg files, like "bootorder", are not under >> "etc/". > > Well bootorder is there so at least it will always fail. > We do have stuff under /rom. > >> Hence the earlier proposal to restrict the user (to under opt/, >> IIRC), rather than ourselves. >> >> Thanks >> Laszlo > > How about we pre-pend opt/ to user-supplied names? > Will fix this without limiting user in any way. (Sorry if this has been addressed in further messages down-thread; I'm not that far yet.) The issues here are that a user implementing custom firmware or OS-level code will have to: (a) take this prefix in account when writing the client code, (b) blob names have a max length of 55 chars IIRC (+ terminating NUL), any fixed prefix would decrease that. Not necessarily a problem, but something to be aware of, at least in the QEMU option parsing. Thanks Laszlo