[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 4/5] fw_cfg: prohibit insertion of duplicate
Gabriel L. Somlo
Re: [Qemu-devel] [PATCH v2 4/5] fw_cfg: prohibit insertion of duplicate fw_cfg file names
Fri, 20 Mar 2015 10:34:21 -0400
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!
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 :)
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...
[Qemu-devel] [PATCH v2 1/5] fw_cfg: add documentation file (docs/specs/fw_cfg.txt), Gabriel L. Somlo, 2015/03/18