From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ1fC-00043A-US for qemu-devel@nongnu.org; Fri, 20 Mar 2015 14:28:55 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YZ1f7-0001Wq-Uw for qemu-devel@nongnu.org; Fri, 20 Mar 2015 14:28:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YZ1f7-0001Wi-Nu for qemu-devel@nongnu.org; Fri, 20 Mar 2015 14:28:49 -0400 Message-ID: <550C66D4.6030602@redhat.com> Date: Fri, 20 Mar 2015 19:28:36 +0100 From: Laszlo Ersek MIME-Version: 1.0 References: <1426724311-9343-1-git-send-email-somlo@cmu.edu> <1426724311-9343-5-git-send-email-somlo@cmu.edu> <550BC35A.3040606@redhat.com> <20150320143420.GP1832@HEDWIG.INI.CMU.EDU> In-Reply-To: <20150320143420.GP1832@HEDWIG.INI.CMU.EDU> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 4/5] fw_cfg: prohibit insertion of duplicate fw_cfg file names List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Gabriel L. Somlo" Cc: matt.fleming@intel.com, mdroth@linux.vnet.ibm.com, rjones@redhat.com, jordan.l.justen@intel.com, "Gabriel L. Somlo" , qemu-devel@nongnu.org, gleb@cloudius-systems.com, kraxel@redhat.com, pbonzini@redhat.com, armbru@redhat.com On 03/20/15 15:34, Gabriel L. Somlo wrote: > On Fri, Mar 20, 2015 at 07:51:06AM +0100, Laszlo Ersek wrote: >> Here's an idea I had this morning. >> >> This series gives equal rank to fw_cfg file names that originate >> internally and those that come from the user, via the command line. >> >> That means that whenever qemu developers want to introduce a new >> fw_cfg file, they can never be sure that the new name will not >> conflict with something a user has already been passing in via the >> command line, for whatever purposes. (Because, well, that's the goal >> of this patchset, to empower the user to pass in fw_cfg files >> independently of qemu developers.) >> >> This looks brittle. How about: >> >> (a) advising users in the docs txt *and in the manual* to use some >> kind of fw_cfg file name prefix, like "usr/" or "opt/", and then >> steering clear of such prefixes in qemu, as far as developers are >> concerned. Or, >> >> (b) automatically prepending "opt/" or "usr/" to all fw_cfg file >> names that come via -fw_cfg (equiv. via [fw_cfg] in the config file), >> and, for developers, steering clear of those prefixes in qemu's >> source. >> >> The C standard and the POSIX standard define lists of identifier >> prefixes (well, patterns) that are reserved for various uses. If a >> program violates that, it might not compile on some platform, or with >> the next release of the compiler on the same platform etc. I think we >> should posit something like this. >> >> Personally I vote (a). Document it, but don't enforce it. >> >> (Assuming that a user-specified fw_cfg file gains traction, and >> becomes popular to the point that qemu wants to expose it itself, >> then qemu can just generate the same file with (eg.) an "etc/" >> prefix. And then firmware (or other guest code) can start looking for >> the file under both prefixes, and give priority to... well, that's >> another policy question; but we're talking mechanism thus far. :)) >> >> Thoughts about (a) vs. (b) vs. neither? > > You're basically saying it'd be nice to keep user-provided commandline > blobs in a separate *namespace* from those inserted programmatically > by QEMU, and I definitely agree! Right. Dunno why I didn't say "namespace"; otherwise I keep dropping that term twice a day. :) > My inner control freak's gut reaction is to vote (b), but I'm sure > theres lots of facets of the issue I haven't considered, so I could > easily be talked out of that selection :) Well, if you implement (b), I certainly won't protest. > Either way, this would go in with patch 5/5 (where the command line > option is being added), so everything up to that point (including > generating an error on dupe fwcfg file names) should probably stay > the way it is... Oh yes, sure. I guess I followed up here only because this would be the patch to catch the conflict. My R-b's stand. Thanks Laszlo