From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49098) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoDJr-0001Mv-Cn for qemu-devel@nongnu.org; Thu, 07 Apr 2016 13:02:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoDJl-0004ii-Ps for qemu-devel@nongnu.org; Thu, 07 Apr 2016 13:02:11 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57835) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoDJl-0004iL-KF for qemu-devel@nongnu.org; Thu, 07 Apr 2016 13:02:05 -0400 References: <1460043243-6198-1-git-send-email-mst@redhat.com> <5706897C.70203@redhat.com> <20160407192713-mutt-send-email-mst@redhat.com> From: Laszlo Ersek Message-ID: <5706928A.5070501@redhat.com> Date: Thu, 7 Apr 2016 19:02:02 +0200 MIME-Version: 1.0 In-Reply-To: <20160407192713-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] fw_cfg: RFQDN rules, documentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Markus Armbruster , "Gabriel L . Somlo" , Paolo Bonzini , qemu-devel@nongnu.org, Gerd Hoffmann On 04/07/16 18:40, Michael S. Tsirkin wrote: > On Thu, Apr 07, 2016 at 06:23:24PM +0200, Laszlo Ersek wrote: >> Should we allow QEMU firmware developers to create special settings, >> to be populated manually by their end-users, that the guest kernel >> would be prevented from seeing? > > Exactly. > >> I don't think so. Namely, in practice, new firmware settings (that are >> to be populated manually by users) will go under "opt/org.seabios/" and >> "opt/org.tianocore.edk2.ovmf/". I couldn't care less if a guest kernel >> user looks at such files. After all, the names *explicitly carry* the >> RFQDN of the intended consumer. If a user violates it, that's his >> problem. (It may become the problem of his downstream users too, but >> that's the same thing.) >> >> So, as long as I understood your question right, I don't think it's >> necessary. > > It's not a question we need to ask ourselves as hardware/qemu designers. > It's a question for the guest kernel - once that exposes > interfaces to applications, it has to maintain them forever. Even for "interfaces" that are transparently passed through from firmware / hardware? I think that shouldn't put compatibility requirements on the kernel. I tend to think about these sysfs (IIRC) entries similarly to ACPI tables, SMBIOS tables, and such. Applications are allowed to see them, yes; the kernel isn't responsible for maintaining them forever. If the hardware changes, or the firmware changes, the applications (that care) will see the change; and the kernel has no responsibility. > This is unlike firmware interfaces - if these are updated > together with firmware, you do not need to maintain > old ones. Anyway, I'll claim lack of jurisdiction here. Thanks Laszlo