[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2] fw_cfg: RFQDN rules, documentation
From: |
Laszlo Ersek |
Subject: |
Re: [Qemu-devel] [PATCH v2] fw_cfg: RFQDN rules, documentation |
Date: |
Thu, 7 Apr 2016 19:02:02 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 |
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