On Thu, Apr 07, 2016 at 12:55:16PM -0400, Gabriel L. Somlo wrote: ... > > > question is, I think: > > > > > > 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. > > And that's why IMHO it's cleaner for that interface to be: > > /sys/firmware/qemu-fw-cfg/by-name/<blob-path>/[key|name|raw|size] > > I really don't think any particular instance of <blob-path> could > reasonably be called an "interface" (and therefore create expectations > of its continued presence forever), or can it ? > > Thanks, > --Gabriel
Generally it's an interface if userspace relies on it. > > This is unlike firmware interfaces - if these are updated > > together with firmware, you do not need to maintain > > old ones.
