[Top][All Lists]

[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.


reply via email to

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