Wenchao Xia <wenchaoq...@gmail.com> writes: > This series address two issues: > > 1. support using enum as discriminator in union. > For example, if we have following define in qapi schema: > { 'enum': 'EnumOne', > 'data': [ 'value1', 'value2', 'value3' ] } > > { 'type': 'UserDefBase0', > 'data': { 'base-string0': 'str', 'base-enum0': 'EnumOne' } } > > Before this series, discriminator in union must be a string, and a > hidden enum type as discriminator is generated. After this series, > qapi schema can directly use predefined enum type: > { 'union': 'UserDefEnumDiscriminatorUnion', > 'base': 'UserDefBase0', > 'discriminator' : 'base-enum0', > 'data': { 'value1' : 'UserDefA', > 'value2' : 'UserDefInherit', > 'value3' : 'UserDefB' } } > > The benefit is that every thing is defined explicitly in schema file, > the discriminator enum type can be used in other API define in schema, > and a compile time check will be put to verify the correctness according > to enum define. Currently BlockdevOptions used discriminator which can > be converted, in the future other union can also use enum discriminator. > > The implement is done by: > 1.1 remember the enum defines by qapi scripts.(patch 1) > 1.2 use the remembered enum define to check correctness at compile > time.(patch 3), more strict check(patch 2) > 1.3 use the same enum name generation rule to avoid C code mismatch, > esp for "case [ENUM_VALUE]" in qapi-visit.c.(patch 4,5) > 1.4 switch the code path, when pre-defined enum type is used as discriminator, > don't generate a hidden enum type, use the enum type instead, add > docs/qapi-code-gen.txt.(Patch 6) > 1.5 test case shows how it looks like.(Patch 7) > 1.6 convert BlockdevOptions. (Patch 8) > > 2. Better enum name generation > Before this patch, AIOContext->A_I_O_CONTEXT, after this patch, > AIOContet->AIO_CONTEXT. Since previous patch has foldered enum > name generation codes into one function, it is done easily by modifying > it.(Patch 9)
With the unwanted try ... except removed from 07/10, series Reviewed-by: Markus Armbruster <arm...@redhat.com> Thanks again for rebasing onto my work!