Re: [Qemu-devel] [PATCH 3/6] qapi: rename prefix QEVENT to Q_EVENT

[Wenchao Xia <xiawenc@linux.vnet.ibm.com>]

于 2013/10/30 0:09, Eric Blake 写道:
> On 10/28/2013 11:22 PM, Wenchao Xia wrote:
>
>>    MONITOR_EVENT seems tide to monitor too much, since it will be present
>> in qapi-schema, I think Q_EVENT_ or QMP_EVENT_KIND would be better?
> I don't have a strong enough opinion on the bikeshed color.
> MONITOR_EVENT implies the event is always associated with delivery over
> a monitor; but how else would you receive an event without a monitor?
   Block code emit event already, when it is packaged as a library
it may need emit to other place. I think event doesn't have to be
bond to monitor, I can modify the qapi script to generate name correctly,
to avoid patch 2, Since it seems not right to have '_' between two capitals.


>>    I am coding v2, which fully support event define in qapi-schema. There
>> is another thing I hope to know your opinion:
>>    Should we support use enum as discriminator?
>>
>> { 'enum': 'QEvent',
>>    'data': [ 'SHUTDOWN', 'POWERDOWN']
>>
>> { 'type': 'QmpEventBase',
>>    'data': { 'event': 'QEvent', 'timestamp': 'EventTimestamp' } }
>>
>> { 'Union': 'QmpEvent',
>>    'base': 'QmpEventBase',
>>    'discriminator': 'event',
> I raised that question when Kevin first added discriminated unions; if I
> recall, the answer was along the lines: "yes, it would be a nice
> addition, but someone would have to code it, and we'd have to teach the
> generator.py to loudly fail if all branches of the enum are not covered
> in the union's data".  So go for it!
   OK, will send it soon.

>
>>    'data': {
>>        'SHUTDOWN'               : 'EventShutdown',
>>        'POWERDOWN'              : 'EventPowerdown'
>>     }
>> }
>>
>>    By default 'QmpEvent' will generate a hidden enum type 'QmpEventKind'.
>> but the hidden type define is needed by query-event, so there is two way
>> to archieve it:
>> 1 just use the hidden type in qapi-schema.json.
>> 2 modified the script to support use predefined enum type.
>>    In my draft code, both can work, but which one do you prefer?
> I'd like to see the addition of an enum-typed discriminator, rather than
> forcing the discriminator to be string-only.
>