Re: [Qemu-devel] [PATCH v2] fw_cfg: RFQDN rules, documentation

[Michael S. Tsirkin]

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.