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

[Wenchao Xia]

于 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.