[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 03/15] hw/ssi: Remove SSIBus from "

From: Paolo Bonzini
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 03/15] hw/ssi: Remove SSIBus from "qemu/typedefs.h"
Date: Tue, 15 Jan 2019 19:02:33 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]