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
