Re: [Qemu-devel] When to use qemu/typedefs.h (was: [PATCH 23/28] numa: Don't include hw/boards.h into sysemu/numa.h)

[Eric Blake]

On 7/30/19 6:01 AM, Markus Armbruster wrote:
> Cc'ing a few more people who might be interested.
> 
> Eduardo Habkost <address@hidden> 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