From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:48293)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1agI6T-0002pF-Kb
	for qemu-devel@nongnu.org; Wed, 16 Mar 2016 16:31:38 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1agI6O-0004nb-IV
	for qemu-devel@nongnu.org; Wed, 16 Mar 2016 16:31:37 -0400
Received: from mx1.redhat.com ([209.132.183.28]:35636)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mst@redhat.com>) id 1agI6O-0004nU-Cs
	for qemu-devel@nongnu.org; Wed, 16 Mar 2016 16:31:32 -0400
Date: Wed, 16 Mar 2016 22:31:28 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Message-ID: <20160316222436-mutt-send-email-mst@redhat.com>
References: <20160316181541.GG12454@HEDWIG.INI.CMU.EDU>
	<56E9A75D.60603@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56E9A75D.60603@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg
 without opt/
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Laszlo Ersek <lersek@redhat.com>
Cc: pbonzini@redhat.com, "Gabriel L. Somlo" <somlo@cmu.edu>, qemu-devel@nongnu.org, armbru@redhat.com, kraxel@redhat.com

On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote:
> OVMF uses this feature for a few flags. They are all called
> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which
> shouldn't be surprising since I seem to have reviewed every patch for
> that file):

Wait a second.  You are saying upsteam OVMF puts files there.
If users add their own flags that happen to be in opt/ovmf/ then
what happens? And how do they *know* they should avoid that?
There's no warning, guest just breaks in various ways.

This is exactly the kind of mess I was worried about. We have a global
namespace with no way to control what goes where.

opt/ was for end users not firmware.

The right thing to do would be for ovmf to reserve itself
a directory under root.

This really needs more thought.  For now I'd suggest we drop the whole
interface from 2.6 and come back to it after 2.6.

-- 
MST