On 7/30/19 6:01 AM, Markus Armbruster wrote: > Cc'ing a few more people who might be interested. > > Eduardo Habkost <ehabk...@redhat.com> writes:
>> Why is it bad to require the inclusion of hw/boards.h just >> because of CPUArchId, but acceptable to require the inclusion of >> qapi-types-machine.h just to be able to write "NodeInfo *nodes" >> instead of "struct NodeInfo *nodes" below? > > hw/boards.h is worse. Both headers pull in qapi/qapi-builtin-types.h > and qapi/qapi-types-common.h, but hw/boards.h pulls in ~60 more. > > That doesn't mean including qapi/qapi-types-common.h is good. > > For better or worse[*], our coding style mandates typedefs. I could live with a switch to kernel style of always writing the 'struct' at every use, instead of using typedefs; but it would have to be a flag-day switchover, preferably aided by Coccinelle. But I'm not holding my breath for it happening. > > We generally declare a typedef name in exactly one place. The obvious > place is together with the type it denotes. > > Non-local users of the type then need to include the header that > declares the typedef name. > > This can lead to inclusion cycles, in particular for complete struct and > union types that need more types for their members. > > We move typedefs to qemu/typedefs.h to break such cycles. > > We also do it to include less, for less frequent recompilation. As this > series demonstrates, we're not very good at that. When to put a typedef > in qemu/typedefs.h for this purpose is not obvious. If we simply put > all of them there, we'd recompile the world every time we add a typedef, > which is pretty much exactly what we're trying to avoid. > > Some of qemu/typedefs.h's typedefs are used in dozens or even hundreds > of other headers. Quite a few only in one. The latter likely should > not be there. > > We occasionally give up and use types directly rather than their typedef > names, flouting the coding style. This patch does. Trades messing with > qemu/typedefs.h for having to write 'struct' a few times. > > Should we give up more? Or not at all? > > Can we have some guidelines on proper use of qemu/typedefs.h? How hard would it be to compute which typedefs already in qemu/typedefs.h are necessary to avoid cyclic inclusion? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
