Paolo Bonzini <[email protected]> writes:
> On 15/01/19 13:56, Thomas Huth wrote:
>> Yes, agreed, removing things from typedefs.h just to add lots of
>> #includes in other files is not really the best idea. I also dropped
>> this patch in v2 of my current PULL request because of this reason.
>> Phil, I suggest to simply drop this patch. What we maybe could do is to
>> split up typedefs.h per subsystem, so that we additionally have a
>> hw/arm/typedefs.h, hw/ppc/typedefs.h etc. in the end, then the
>> target-specific typedefs would not clutter the common qemu/typedefs.h
>> file anymore.
>
> I disagree. The *inclusions* of target-specific typedefs.h would then
> clutter something.
>
> For the (important, mind) case of circular includes, allowing struct in
> prototypes pretty much solves the issues, and a subsystem-specific
> typedefs.h is another solution according to maintainer's discretion.
>
> In this case, however, keeping subsystems self-contained is a good
> reason to apply the patch. Having SSIBus in typedefs.h means that the
> next SSI type has a higher chance of being added to typedefs.h even if
> it's not necessary.
typedefs.h churn appars to be a non-problem:
$ git-log --oneline --since 'one year ago' include/qemu/typedefs.h
a98c370c46 typedefs: (Re-)sort entries alphabetically
aec90730fb numa: Match struct to typedef name
7cfda775e5 move ObjectClass to typedefs.h
ea134caa08 typedefs: add QJSON
201376cb9e typedefs: Remove PcGuestInfo from qemu/typedefs.h
9f5c734d59 Typedef the subtypes of QObject in qemu/typedefs.h, too
e70372fcaf lockable: add QemuLockable
> Sometimes we need to take patches that seem unnecessary in order to keep
> the codebase tidy. Think of the churn that was the introduction of
> hw/SUBSYSTEM. It was painful and it added all the complexity to the
> Makefiles in order to support recursive Makefile.objs in our
> not-that-recursive makefiles. However, it made MAINTAINERS usable and
> now, a few years later, few of us would probably be happy to go back to
> the flat hw/ directory.
What problem exactly are we trying to solve here?
To the best of my knowledge, typedefs.h has been working just fine for
us, and I can't see why it shouldn't continue to work just fine.
