Re: [dpdk-dev] [PATCH v1 0/5] introduce IWYU

[Bruce Richardson <bruce.richardson@intel.com>]

On Mon, Oct 04, 2021 at 08:55:35AM -0700, Stephen Hemminger wrote:
> On Mon,  4 Oct 2021 10:10:53 +0000
> Sean Morrissey <sean.morrissey@intel.com> wrote:
> 
> > This patchset introduces the include-what-you-use script which removes
> > unused header includes. IWYU GitHub:
> > 
> > https://github.com/include-what-you-use/include-what-you-use
> > 
> > Along with the script there are some patches which make a start on
> > removing unneeded headers.
> > 
> > Sean Morrissey (5):
> >   devtools: script to remove unused headers includes
> >   lib/telemetry: remove unneeded header includes
> >   lib/ring: remove unneeded header includes
> >   lib/kvargs: remove unneeded header includes
> >   lib/eal: remove unneeded header includes
> > 
> >  devtools/process_iwyu.py               | 109 +++++++++++++++++++++++++
<snip>
> >  49 files changed, 110 insertions(+), 213 deletions(-)
> >  create mode 100755 devtools/process_iwyu.py
> > 
> 
> There is a risk of breaking builds on other platforms.
> How can you be sure the include files (especially auto generated list)
> are the same in Linux, FreeBSD and Windows as well as the special
> versions of libc (musl etc).

Yep, there is a risk of that but:

a) that's why we have automated build checks of various types in
test-meson-builds and why we have automated testing of patches in a number
of different labs reported out in patchwork.
b) if we say we can't risk it, we then can't gain much/any real benefit
from tools like iwyu - a tool that you have encouraged use of a number of
times :-).

Overall, I think this is a good thing for DPDK, and I encouraged Sean to
look into it, because it just helps with code quality in DPDK. However,
it's also true that there is risk in this, so I think the approach of only
doing a few libraries initially - so we can see how it works out - is
probably best, rather than trying to do the whole codebase in one go. I
think it's also true to say that the risk is greatest with EAL, so if it
can be cleaned up, cleaning the other libs and maybe then drivers should be
easier. Having the whole processing automated will also help with this, as -
if we want to minimize risk - the work on each driver can be done by the
driver maintainers themselves, who are best placed to know the
platform-specific issues for that code.

Regards,
/Bruce