qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, Paolo Bonzini <pbonzini@redhat.com>,
	"Gabriel L . Somlo" <somlo@cmu.edu>,
	Laszlo Ersek <lersek@redhat.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation
Date: Sat, 9 Apr 2016 20:05:32 +0300	[thread overview]
Message-ID: <20160409200141-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <87twjcvz7o.fsf@dusky.pond.sub.org>

On Fri, Apr 08, 2016 at 06:31:55PM +0200, Markus Armbruster wrote:
> Interface and doc review only.  Sorry for the delay, I was on vacation.
> 
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > This requires that all -fw_cfg command line users use names of the form
> 
> What's "this"?  Do you mean "Require that ..."?
> 
> > opt/RFQDN/: such names are compatible with QEMU 2.4 and 2.5 as well as
> > future QEMU versions.
> 
> I'd reserve names with dots before the first '/' for users, and use
> RFQDN/ without opt/.  But I can live with opt/.
> >
> > As ability to insert fw_cfg entries in QEMU root is useful for
> > firmware development, add a special prefix: unsupported/root/ that
> > allows that, while making sure users are aware it's unsupported.
> >
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Gabriel L. Somlo <somlo@cmu.edu>
> > Cc: Laszlo Ersek <lersek@redhat.com>
> > Cc: Markus Armbruster <armbru@redhat.com>
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Reviewed-by: Laszlo Ersek <lersek@redhat.com>
> > ---
> >
> > I put this in my tree for now. If anyone has an issue with this,
> > please speak up!
> [...]
> > diff --git a/docs/specs/fw_cfg.txt b/docs/specs/fw_cfg.txt
> > index 5414140..41ce9ca 100644
> > --- a/docs/specs/fw_cfg.txt
> > +++ b/docs/specs/fw_cfg.txt
> > @@ -210,29 +210,29 @@ the following syntax:
> >  
> >      -fw_cfg [name=]<item_name>,file=<path>
> >  
> > -where <item_name> is the fw_cfg item name, and <path> is the location
> > -on the host file system of a file containing the data to be inserted.
> > -
> > -Small enough items may be provided directly as strings on the command
> > -line, using the syntax:
> > +Or
> >  
> >      -fw_cfg [name=]<item_name>,string=<string>
> >  
> > -The terminating NUL character of the content <string> will NOT be
> > -included as part of the fw_cfg item data, which is consistent with
> > -the absence of a NUL terminator for items inserted via the file option.
> > +See QEMU man page for more documentation.
> >  
> > -Both <item_name> and, if applicable, the content <string> are passed
> > -through by QEMU without any interpretation, expansion, or further
> > -processing. Any such processing (potentially performed e.g., by the shell)
> > -is outside of QEMU's responsibility; as such, using plain ASCII characters
> > -is recommended.
> > +Using item_name with plain ASCII characters only is recommended.
> >  
> 
> My first reaction was "wait a second, why are you throwing away useful
> information?"  I had to read on to realize you're *moving* it, to
> qemu-options.hx.  That's fine.  Announcing such moves in the commit
> message makes review easier.
> 
> > -NOTE: Users *SHOULD* choose item names beginning with the prefix "opt/"
> > +Users MUST choose item names beginning with the prefix "opt/RFQDN/"
> 
> Preexisting: no need to shout.
> 
> >  when using the "-fw_cfg" command line option, to avoid conflicting with
> > -item names used internally by QEMU. For instance:
> > +item names used internally by QEMU, or by firmware. For instance:
> >  
> > -    -fw_cfg name=opt/my_item_name,file=./my_blob.bin
> > +    -fw_cfg name=opt/com.mycompany/guestagent/guestblob,file=./my_blob.bin
> 
> Neglects to spell out the obvious: RFQDN is a reverse fully qualified
> domain name which you control.
> 
> I'm not sure I agree with the change from "should" to "must".  What
> happens when a user uses a conflicting name?  Can you categorically rule
> out that specifying a conflicting name could ever be useful, e.g. for
> debugging or testing purposes?  If not, then "must" is wrong.
> 
> > -Similarly, QEMU developers *SHOULD NOT* use item names prefixed with
> > +Similarly, QEMU developers MUST NOT use item names prefixed with
> >  "opt/" when inserting items programmatically, e.g. via fw_cfg_add_file().
> 
> Here, "must not" is appropriate.
> 
> > +
> > +For historical reasons "opt/ovmf/" is reserved for use with the OVMF firmware.
> 
> Comma after reasons.
> 
> Here's how I'd skin this cat:
> 
>     Names beginning with "opt/" are reserved for users.  QEMU will never
>     create entries with such names unless explicitly ordered by the
>     user.
> 
>     To avoid clashes among different users, it is strongly recommended
>     that you use names beginning with opt/RFQDN/, where RFQDN is a
>     reverse fully qualified domain name you control.  For instance, if
>     SeaBIOS wanted to define additional names, prefix "opt/org.seabios/"
>     would be appropriate.
> 
>     For historical reasons, "opt/ovmf/" is reserved for OVMF firmware.
> 

Markus, I don't know what to do with your comments below.
I *really* do not want to reopen this can of worms after
I am finally getting some acks.

Can you or can you not live with the scheme proposed with this patch?

-- 
MST

  reply	other threads:[~2016-04-09 17:05 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-08  7:54 [Qemu-devel] [PATCH v3] fw_cfg: RFQDN rules, documentation Michael S. Tsirkin
2016-04-08 16:31 ` Markus Armbruster
2016-04-09 17:05   ` Michael S. Tsirkin [this message]
2016-04-11 11:04     ` Markus Armbruster
2016-04-11 11:31       ` Michael S. Tsirkin
2016-04-13  8:59         ` Markus Armbruster
2016-04-13 11:00           ` Michael S. Tsirkin
2016-04-13 16:17             ` Markus Armbruster
2016-04-13 17:53               ` Michael S. Tsirkin
2016-04-14  7:36                 ` Markus Armbruster
2016-04-14  8:10                   ` Michael S. Tsirkin
2016-04-14 11:28                     ` Markus Armbruster
2016-04-13 14:44           ` Michael S. Tsirkin
2016-04-13 16:19             ` Markus Armbruster
2016-04-13 17:53               ` Michael S. Tsirkin
2016-04-14  7:39                 ` Markus Armbruster
2016-04-14  8:11                   ` Michael S. Tsirkin
2016-04-14 11:29                     ` Markus Armbruster
2016-04-14 12:13                       ` Michael S. Tsirkin
2016-04-15 15:39                         ` Markus Armbruster
2016-04-17  6:55                           ` Michael S. Tsirkin
2016-04-18 16:42           ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160409200141-mutt-send-email-mst@redhat.com \
    --to=mst@redhat.com \
    --cc=armbru@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=lersek@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=somlo@cmu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).