• E
    qapi: Lazy creation of array types · 9f08c8ec
    Eric Blake 提交于
    Commit ac88219a had several TODO markers about whether we needed
    to automatically create the corresponding array type alongside
    any other type.  It turns out that most of the time, we don't!
    
    There are a few exceptions: 1) We have a few situations where we
    use an array type in internal code but do not expose that type
    through QMP; fix it by declaring a dummy type that forces the
    generator to see that we want to use the array type.
    
    2) The builtin arrays (such as intList for QAPI ['int']) must
    always be generated, because of the way our QAPI_TYPES_BUILTIN
    compile guard works: we have situations (at the very least
    tests/test-qmp-output-visitor.c) that include both top-level
    "qapi-types.h" (via "error.h") and a secondary
    "test-qapi-types.h". If we were to only emit the builtin types
    when used locally, then the first .h file would not include all
    types, but the second .h does not declare anything at all because
    the first .h set QAPI_TYPES_BUILTIN, and we would end up with
    compilation error due to things like unknown type 'int8List'.
    
    Actually, we may need to revisit how we do type guards, and
    change from a single QAPI_TYPES_BUILTIN over to a different
    usage pattern that does one #ifdef per qapi type - right now,
    the only types that are declared multiple times between two qapi
    .json files for inclusion by a single .c file happen to be the
    builtin arrays.  But now that we have QAPI 'include' statements,
    it is logical to assume that we will soon reach a point where
    we want to reuse non-builtin types (yes, I'm thinking about what
    it will take to add introspection to QGA, where we will want to
    reuse the SchemaInfo type and friends).  One #ifdef per type
    will help ensure that generating the same qapi type into more
    than one qapi-types.h won't cause collisions when both are
    included in the same .c file; but we also have to solve how to
    avoid creating duplicate qapi-types.c entry points.  So that
    is a problem left for another day.
    
    Generated code for qapi-types and qapi-visit is drastically
    reduced; less than a third of the arrays that were blindly
    created were actually needed (a quick grep shows we dropped
    from 219 to 69 *List types), and the .o files lost more than
    30% of their bulk.  [For best results, diff the generated
    files with 'git diff --patience --no-index pre post'.]
    
    Interestingly, the introspection output is unchanged - this is
    because we already cull all types that are not indirectly
    reachable from a command or event, so introspection was already
    using only a subset of array types.  The subset of types
    introspected is now a much larger percentage of the overall set
    of array types emitted in qapi-types.h (since the larger set
    shrunk), but still not 100% (evidence that the array types
    emitted for our new Dummy structs, and the new struct itself,
    don't affect QMP).
    Signed-off-by: NEric Blake <eblake@redhat.com>
    Message-Id: <1444710158-8723-9-git-send-email-eblake@redhat.com>
    [Moved array info tracking to a later patch]
    Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
    9f08c8ec
qapi-schema.json 97.6 KB