[PATCH 0/2] hw/vfio: Build various target-independent objects once

[PATCH 0/2] hw/vfio: Build various target-independent objects once

[Philippe Mathieu-Daudé]

Remove the unused 'exec/ram_addr.h' from migration.o.
This was the only reason this file is built per target.
Move other target-independent objects to meson's softmmu
source set.

Philippe Mathieu-Daudé (2):
  hw/vfio/migration: Remove unused 'exec/ram_addr.h' header
  hw/vfio: Build various target-independent objects once

 hw/vfio/meson.build | 13 ++++++++-----
 hw/vfio/migration.c |  1 -
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.38.1

[PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/vfio/migration.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
index a2c3d9bade..f9ac074c63 100644
--- a/hw/vfio/migration.c
+++ b/hw/vfio/migration.c
@@ -24,7 +24,6 @@
 #include "migration/misc.h"
 #include "qapi/error.h"
 #include "exec/ramlist.h"
-#include "exec/ram_addr.h"
 #include "pci.h"
 #include "trace.h"
 #include "hw/hw.h"
-- 
2.38.1

[PATCH 2/2] hw/vfio: Build various target-independent objects once

[Philippe Mathieu-Daudé]

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
---
 hw/vfio/meson.build | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/hw/vfio/meson.build b/hw/vfio/meson.build
index da9af297a0..a1ed62245a 100644
--- a/hw/vfio/meson.build
+++ b/hw/vfio/meson.build
@@ -1,19 +1,22 @@
+softmmu_ss.add(files(
+  'migration.c',
+))
+softmmu_ss.add(when: 'CONFIG_VFIO_PCI', if_true: files('display.c'))
+softmmu_ss.add(when: 'CONFIG_VFIO_XGMAC', if_true: files('calxeda-xgmac.c'))
+softmmu_ss.add(when: 'CONFIG_VFIO_AMD_XGBE', if_true: files('amd-xgbe.c'))
+softmmu_ss.add(when: 'CONFIG_VFIO_IGD', if_true: files('igd.c'))
+
 vfio_ss = ss.source_set()
 vfio_ss.add(files(
   'common.c',
   'spapr.c',
-  'migration.c',
 ))
 vfio_ss.add(when: 'CONFIG_VFIO_PCI', if_true: files(
-  'display.c',
   'pci-quirks.c',
   'pci.c',
 ))
 vfio_ss.add(when: 'CONFIG_VFIO_CCW', if_true: files('ccw.c'))
 vfio_ss.add(when: 'CONFIG_VFIO_PLATFORM', if_true: files('platform.c'))
-vfio_ss.add(when: 'CONFIG_VFIO_XGMAC', if_true: files('calxeda-xgmac.c'))
-vfio_ss.add(when: 'CONFIG_VFIO_AMD_XGBE', if_true: files('amd-xgbe.c'))
 vfio_ss.add(when: 'CONFIG_VFIO_AP', if_true: files('ap.c'))
-vfio_ss.add(when: 'CONFIG_VFIO_IGD', if_true: files('igd.c'))
 
 specific_ss.add_all(when: 'CONFIG_VFIO', if_true: vfio_ss)
-- 
2.38.1

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Cédric Le Goater]

On 2/27/23 11:32, Philippe Mathieu-Daudé wrote:
> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>


Reviewed-by: Cédric Le Goater <clg@redhat.com>

Thanks,

C.


> ---
>   hw/vfio/migration.c | 1 -
>   1 file changed, 1 deletion(-)
> 
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index a2c3d9bade..f9ac074c63 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -24,7 +24,6 @@
>   #include "migration/misc.h"
>   #include "qapi/error.h"
>   #include "exec/ramlist.h"
> -#include "exec/ram_addr.h"
>   #include "pci.h"
>   #include "trace.h"
>   #include "hw/hw.h"

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Alex Williamson]

On Mon, 27 Feb 2023 11:32:57 +0100
Philippe Mathieu-Daudé <philmd@linaro.org> wrote:

> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Empty commit logs are a pet peeve of mine, there must be some sort of
motivation for the change, something that changed to make this
possible, or perhaps why this was never necessary.  Thanks,

Alex

> ---
>  hw/vfio/migration.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/hw/vfio/migration.c b/hw/vfio/migration.c
> index a2c3d9bade..f9ac074c63 100644
> --- a/hw/vfio/migration.c
> +++ b/hw/vfio/migration.c
> @@ -24,7 +24,6 @@
>  #include "migration/misc.h"
>  #include "qapi/error.h"
>  #include "exec/ramlist.h"
> -#include "exec/ram_addr.h"
>  #include "pci.h"
>  #include "trace.h"
>  #include "hw/hw.h"

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Peter Maydell]

On Mon, 27 Feb 2023 at 15:46, Alex Williamson
<alex.williamson@redhat.com> wrote:
>
> On Mon, 27 Feb 2023 11:32:57 +0100
> Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>
> Empty commit logs are a pet peeve of mine, there must be some sort of
> motivation for the change, something that changed to make this
> possible, or perhaps why this was never necessary.  Thanks,

I generally agree, but "this file doesn't actually need to
include this header" seems straightforward enough that the commit
subject says everything you'd want to say about it.
The underlying reason is going to be one of:
 * this used to be needed, but somewhere along the line the
   thing the file needs moved to a different header
 * this used to be needed, but the code in the file changed
   and no longer uses the thing the header was providing
 * this was never needed, and the include was just cut-n-pasted
   from a different file when the file was originally written

Tracking down which of those is the case for every single
"file is including unnecessary headers" cleanup seems like
a lot of work trawling through git histories and doesn't
really provide any interesting information.

thanks
-- PMM

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Alex Bennée]

Alex Williamson <alex.williamson@redhat.com> writes:

> On Mon, 27 Feb 2023 11:32:57 +0100
> Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>
> Empty commit logs are a pet peeve of mine, there must be some sort of
> motivation for the change, something that changed to make this
> possible, or perhaps why this was never necessary.  Thanks,

I think that is a little unfair for this case as the motivation and
action are all covered by the summary line. Granted the overall goal is
covered by the cover letter and the following patch however for this
patch I would hope its self explanatory.

Anyway:

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Alex Williamson]

On Mon, 27 Feb 2023 16:04:16 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Mon, 27 Feb 2023 at 15:46, Alex Williamson
> <alex.williamson@redhat.com> wrote:
> >
> > On Mon, 27 Feb 2023 11:32:57 +0100
> > Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> >  
> > > Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>  
> >
> > Empty commit logs are a pet peeve of mine, there must be some sort of
> > motivation for the change, something that changed to make this
> > possible, or perhaps why this was never necessary.  Thanks,  
> 
> I generally agree, but "this file doesn't actually need to
> include this header" seems straightforward enough that the commit
> subject says everything you'd want to say about it.
> The underlying reason is going to be one of:
>  * this used to be needed, but somewhere along the line the
>    thing the file needs moved to a different header
>  * this used to be needed, but the code in the file changed
>    and no longer uses the thing the header was providing
>  * this was never needed, and the include was just cut-n-pasted
>    from a different file when the file was originally written
> 
> Tracking down which of those is the case for every single
> "file is including unnecessary headers" cleanup seems like
> a lot of work trawling through git histories and doesn't
> really provide any interesting information.

OTOH, not providing any justification shows a lack of due diligence.
Even a justification to the extent of "This passes gitlab CI across all
architectures after removing the include" or copying from the cover
letter to explain that this include is the only reason the file is
built per target would be an improvement.

I find that empty commit logs create a barrier to entry for
participation in a project, there is always some motivation that can
help provide a better commit that doesn't force an undue burden on the
submitter.  Thanks,

Alex

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Alex Williamson]

On Mon, 27 Feb 2023 16:24:16 +0000
Alex Bennée <alex.bennee@linaro.org> wrote:

> Alex Williamson <alex.williamson@redhat.com> writes:
> 
> > On Mon, 27 Feb 2023 11:32:57 +0100
> > Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
> >  
> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>  
> >
> > Empty commit logs are a pet peeve of mine, there must be some sort of
> > motivation for the change, something that changed to make this
> > possible, or perhaps why this was never necessary.  Thanks,  
> 
> I think that is a little unfair for this case as the motivation and
> action are all covered by the summary line. Granted the overall goal is
> covered by the cover letter and the following patch however for this
> patch I would hope its self explanatory.

The commit title only conveys that the include is unused and the action
to therefore remove it.  The motivation is actually to create target
independent objects and the specific reasoning here is that not only is
this include file unnecessary, but forces per target builds.

This is exactly the "barrier to entry" I mention to Peter, it's obvious
to the experts in the crowd, but it provides no underlying direction
for those who might be more novice.  There is always some reasoning
that can be included in a commit log beyond the simple "a therefore b"
of the commit title.  Thanks,

Alex

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Philippe Mathieu-Daudé]

Hi Alex,

On 27/2/23 17:34, Alex Williamson wrote:
> On Mon, 27 Feb 2023 16:04:16 +0000
> Peter Maydell <peter.maydell@linaro.org> wrote:
> 
>> On Mon, 27 Feb 2023 at 15:46, Alex Williamson
>> <alex.williamson@redhat.com> wrote:
>>>
>>> On Mon, 27 Feb 2023 11:32:57 +0100
>>> Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>>   
>>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>>
>>> Empty commit logs are a pet peeve of mine, there must be some sort of
>>> motivation for the change, something that changed to make this
>>> possible, or perhaps why this was never necessary.  Thanks,
>>
>> I generally agree, but "this file doesn't actually need to
>> include this header" seems straightforward enough that the commit
>> subject says everything you'd want to say about it.
>> The underlying reason is going to be one of:
>>   * this used to be needed, but somewhere along the line the
>>     thing the file needs moved to a different header
>>   * this used to be needed, but the code in the file changed
>>     and no longer uses the thing the header was providing
>>   * this was never needed, and the include was just cut-n-pasted
>>     from a different file when the file was originally written
>>
>> Tracking down which of those is the case for every single
>> "file is including unnecessary headers" cleanup seems like
>> a lot of work trawling through git histories and doesn't
>> really provide any interesting information.
> 
> OTOH, not providing any justification shows a lack of due diligence.
> Even a justification to the extent of "This passes gitlab CI across all
> architectures after removing the include" or copying from the cover
> letter to explain that this include is the only reason the file is
> built per target would be an improvement.
> 
> I find that empty commit logs create a barrier to entry for
> participation in a project, there is always some motivation that can
> help provide a better commit that doesn't force an undue burden on the
> submitter.  Thanks,

You are totally right and I apologize for such low quality patch.
If I want these cleanups to scale (being done by other) I certainly
need to explain why they are useful. Eventually copy/pasting the
same reasoning for class of change.
OTOH I sometime feel these cleanups are more noise than anything
to maintainers, and various end up queued via qemu-trivial@
(which isn't what I expect for trivial@).
We have a bit of both, maintainers tired by poor descriptions /
justifications, and contributors exhausted to get trivial patch
- for their perspective - merged without too much doc.

This patch you insist on is a good one-line example of a pattern
we should start cleaning: being overzealous with header included
pull so many stuff that we shoot on our foot and end in weird
corner cases, such here making an object target-dependent when
it isn't.
target-dependent objects add build complexity, and delay us from
the goal of single binary and heterogeneous emulation.

Good English explanation for non-English native speaker is not
easy as native speaker, but usually the community is opened and
bare with that barrier.

I'll reword to something work committing and referring to later,
when looking at git history.

Thanks for insisting in improving us!

Phil.

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Markus Armbruster]

Alex Williamson <alex.williamson@redhat.com> writes:

> On Mon, 27 Feb 2023 16:24:16 +0000
> Alex Bennée <alex.bennee@linaro.org> wrote:
>
>> Alex Williamson <alex.williamson@redhat.com> writes:
>> 
>> > On Mon, 27 Feb 2023 11:32:57 +0100
>> > Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>> >  
>> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>  
>> >
>> > Empty commit logs are a pet peeve of mine, there must be some sort of
>> > motivation for the change, something that changed to make this
>> > possible, or perhaps why this was never necessary.  Thanks,  
>> 
>> I think that is a little unfair for this case as the motivation and
>> action are all covered by the summary line. Granted the overall goal is
>> covered by the cover letter and the following patch however for this
>> patch I would hope its self explanatory.
>
> The commit title only conveys that the include is unused and the action
> to therefore remove it.  The motivation is actually to create target
> independent objects and the specific reasoning here is that not only is
> this include file unnecessary, but forces per target builds.

I've been guilty of submitting patches with just a subject line, too.
E.g. commit 6f1e91f716a (error: Drop superfluous #include
"qapi/qmp/qerror.h"): I could have written that the header's contents
should go away, and the less we include it, the better.  I should have.

> This is exactly the "barrier to entry" I mention to Peter, it's obvious
> to the experts in the crowd, but it provides no underlying direction
> for those who might be more novice.  There is always some reasoning
> that can be included in a commit log beyond the simple "a therefore b"
> of the commit title.  Thanks,

Sometimes, the motivation is so obvious that omitting it for brevity's
sake feels harmless enough.  E.g. for commit 15b7646c7d0 (monitor: Drop
unnecessary includes) it's really just "include less to remake less".

Of course, when you explain motivation in the cover letter, it's almost
certainly best to explain it again in the commit messages.

Re: [PATCH 1/2] hw/vfio/migration: Remove unused 'exec/ram_addr.h' header

[Thomas Huth]

On 27/02/2023 17.04, Peter Maydell wrote:
> On Mon, 27 Feb 2023 at 15:46, Alex Williamson
> <alex.williamson@redhat.com> wrote:
>>
>> On Mon, 27 Feb 2023 11:32:57 +0100
>> Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>>
>> Empty commit logs are a pet peeve of mine, there must be some sort of
>> motivation for the change, something that changed to make this
>> possible, or perhaps why this was never necessary.  Thanks,
> 
> I generally agree, but "this file doesn't actually need to
> include this header" seems straightforward enough that the commit
> subject says everything you'd want to say about it.

But not giving any description at all is really just bad style, we should 
avoid it. And in this case, there is even a good reason that should be 
mentioned here (e.g. "This header was the only reason this file needed to be 
built per target"). So I think it's fair to ask for a proper commit log 
message here.

  Thomas