Re: [Qemu-block] [Qemu-devel] [PATCH v3 3/5] block: qobject_is_equal() in bdrv_reopen_prepare()

[Eric Blake]

On 07/03/2017 08:01 AM, Max Reitz wrote:
> On 2017-07-03 14:51, Eric Blake wrote:
>> On 07/03/2017 07:25 AM, Max Reitz wrote:
>>> Currently, bdrv_reopen_prepare() assumes that all BDS options are
>>> strings. However, this is not the case if the BDS has been created
>>> through the json: pseudo-protocol or blockdev-add.
>>>
>>> Note that the user-invokable reopen command is an HMP command, so you
>>
>> s/invokable/invocable/
> 
> I was asking this myself when writing this commit message and actually
> consulted Wiktionary: https://en.wiktionary.org/wiki/invokable

My intuitive reasoning for favoring 'c' is that we spell it
"invocation", not "invokation", even if the short form is "invoke".

But I also consulted dictionary.com before writing my original reply:
http://www.dictionary.com/browse/invocable
which pulls up "invoke" as the primary, and only lists "invocable" (and
not "invokable") as the related form adjective.

Meanwhile, you are correct that wiktionary does list both forms as
alternates of one another, so I can live with the 'k' even though it
looks odd.


>>> +             * all options.  For now, this is not too big of an issue 
>>> because
>>> +             * the user simply can not specify options which cannot be 
>>> changed
>>
>> Seeing "can not" usually looks wrong for "cannot"; but here, it is
>> grammatically correct.  But better would be "the user can simply not
>> specify" or "the user can simply avoid specifying options".
> 
> Awww, I deliberately designed the sentence so I could use "can not". :-)
> 
> (and even contrast it with the following "cannot"!)

Maybe it's just that I'm being thrown off by the placement of 'simply';
as a native speaker, I have an easier time parsing "can simply not" than
I do "simply can not", maybe because of where the emphasis of "simply"
is falling.  Which is perhaps weird, because in the infinitive form
(coming up with a construct that uses "to" instead of "can"), I note
that "it is possible to simply not specify options" is a split
infinitive (which style guides tell you to avoid, even though I think it
is acceptable); while "it is possible simply to not specify options"
satisfies more style guides.

But since you are intentionally doing it for the play on words,

> 
>>> +             * anyway, so they will stay unchanged. */
>>
>> The grammar tweak is minor, so:
>> Reviewed-by: Eric Blake <address@hidden>
> Please let me keep it :-)

you can keep it.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature