> On Jan 16, 2017, at 11:51 AM, Eric Blake <ebl...@redhat.com> wrote: > > On 01/16/2017 01:20 PM, b...@skyportsystems.com > <mailto:b...@skyportsystems.com> wrote: >> From: Ben Warren <b...@skyportsystems.com <mailto:b...@skyportsystems.com>> > > meta-comment: This message was sent with headers: >> Message-Id: >> <d8737523bcb760c29d8d5ca9bd86800fca9cb3c1.1484594095.git....@skyportsystems.com >> >> <mailto:d8737523bcb760c29d8d5ca9bd86800fca9cb3c1.1484594095.git....@skyportsystems.com>> >> In-Reply-To: <cover.1484593565.git....@skyportsystems.com >> <mailto:cover.1484593565.git....@skyportsystems.com>> >> References: <cover.1484593565.git....@skyportsystems.com >> <mailto:cover.1484593565.git....@skyportsystems.com>> >> In-Reply-To: <cover.1484594095.git....@skyportsystems.com >> <mailto:cover.1484594095.git....@skyportsystems.com>> >> References: <cover.1484594095.git....@skyportsystems.com >> <mailto:cover.1484594095.git....@skyportsystems.com>> > > while your cover letter's actual headers included: >> Message-Id: <cover.1484593565.git....@skyportsystems.com >> <mailto:cover.1484593565.git....@skyportsystems.com>> > > I don't know how you got your sending side to use two different sets of > In-Reply-To, but it breaks at least Thunderbird's abilities to rethread > the messages (thunderbird apparently only pays attention to the last > header, while only the first one would cause correct threading). > Hmm, I created the patches using “git format-patch” with the —thread switch, then ‘git send-email’, which is usually a solid combination. I’ll dry-run it next time to make sure things are threaded properly. Sorry. > >> >> Signed-off-by: Ben Warren <b...@skyportsystems.com >> <mailto:b...@skyportsystems.com>> >> Cc: Gal Hammer <gham...@redhat.com <mailto:gham...@redhat.com>> > > If you are basing this patch off of earlier work (for example, you > mentioned Igor's work), you may need additional S-o-b lines for work you > copied from the earlier versions. > yes, I used a previous patch set as a baseline and want to make sure credit goes to whoever did the real work. In this case, Gal Hammer was the original author, so I CC’d Him (or her) hoping to get an SOB. Should that be handled out-of-band? >> --- >> docs/specs/vmgenid.txt | 38 ++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 38 insertions(+) >> create mode 100644 docs/specs/vmgenid.txt >> >> diff --git a/docs/specs/vmgenid.txt b/docs/specs/vmgenid.txt >> new file mode 100644 >> index 0000000..afc1717 >> --- /dev/null >> +++ b/docs/specs/vmgenid.txt >> @@ -0,0 +1,38 @@ >> +VIRTUAL MACHINE GENERATION ID >> +============================= >> + >> +Copyright (C) 2016 Red Hat, Inc. > > Claiming Red Hat copyright makes it sound like you are basing this off > an earlier version. That is the correct thing to do if you indeed > copied something with Red Hat copyright, but seems weird if you wrote it > from scratch. Same as above, I reworked much of this document, but a great deal is not my original. Guidance on the right way to do this is appreciated. > >> +Copyright (C) 2016 Skyport Systems, Inc. > > Do you want to claim 2017 as well? > Good catch, I haven’t touched the file this year, but that makes sense. > >> + >> +The vmgenid device is a sysbus device with the ACPI ID >> "QEMU_Gen_Counter_V1". >> + >> +The device has one properties, which can be set using the command line > > s/properties/property/ Will fix. > >> +argument or the QMP interface: >> + guid - sets the value of the GUID >> +For example: >> +QEMU -device vmgenid,guid="324e6eaf-d1d1-4bf6-bf41-b9bb6c91fb87" >> + > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org <http://libvirt.org/>
smime.p7s
Description: S/MIME cryptographic signature
