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. 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. Paolo
