qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH V4 4/4] fw_cfg: insert fw_cfg file blobs via qem


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH V4 4/4] fw_cfg: insert fw_cfg file blobs via qemu cmdline
Date: Mon, 1 Jun 2015 12:42:04 +0200

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.

-- 
MST



reply via email to

[Prev in Thread] Current Thread [Next in Thread]