Re: [Qemu-arm] [Qemu-devel] [PATCH 03/15] hw/ssi: Remove SSIBus from "qemu/typedefs.h"

[Markus Armbruster]

Paolo Bonzini <address@hidden> 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.