Re: [Qemu-devel] [PATCH v2 4/5] fw_cfg: prohibit insertion of duplicate fw_cfg file names

[Laszlo Ersek <lersek@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