Paolo Bonzini <pbonz...@redhat.com> 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.