Received-SPF: pass (google.com: domain of linux-kernel+bounces-137282-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <20240408185520.1550865-1-namhyung@kernel.org> <20240408185520.1550865-2-namhyung@kernel.org>
 <874jcb9etk.fsf@intel.com> <ZhTwPLliHXKPAJUQ@gmail.com> <87pluy972m.fsf@intel.com>
In-Reply-To: <87pluy972m.fsf@intel.com>
From: Namhyung Kim <namhyung@kernel.org>
Date: Tue, 9 Apr 2024 08:58:55 -0700
Message-ID: <CAM9d7cizO8j3tLjxiVKh4qw3dOzqKmUKZg8BZwaCF=ChmbX81A@mail.gmail.com>
Subject: Re: [PATCH 1/9] tools/include: Sync uapi/drm/i915_drm.h with the
 kernel sources
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ingo Molnar <mingo@kernel.org>, Arnaldo Carvalho de Melo <acme@kernel.org>, Ian Rogers <irogers@google.com>, 
	Kan Liang <kan.liang@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>, 
	Adrian Hunter <adrian.hunter@intel.com>, Peter Zijlstra <peterz@infradead.org>, 
	LKML <linux-kernel@vger.kernel.org>, linux-perf-users@vger.kernel.org, 
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, 
	Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, 
	dri-devel@lists.freedesktop.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello,

On Tue, Apr 9, 2024 at 3:14=E2=80=AFAM Jani Nikula <jani.nikula@linux.intel=
com> wrote:
>
> On Tue, 09 Apr 2024, Ingo Molnar <mingo@kernel.org> wrote:
> > * Jani Nikula <jani.nikula@linux.intel.com> wrote:
> >
> >> On Mon, 08 Apr 2024, Namhyung Kim <namhyung@kernel.org> wrote:
> >> > To pick up changes from:
> >> >
> >> >    b112364867499 ("drm/i915: Add GuC submission interface version qu=
ery")
> >> >    5cf0fbf763741 ("drm/i915: Add some boring kerneldoc")
> >> >
> >> > This should be used to beautify DRM syscall arguments and it address=
es
> >> > these tools/perf build warnings:
> >> >
> >> >   Warning: Kernel ABI header differences:
> >> >     diff -u tools/include/uapi/drm/i915_drm.h include/uapi/drm/i915_=
drm.h
> >>
> >> All these years and I never realized there are header copies
> >> there. But... why copies?
> >
> > It's better than all the alternatives we tried so far:
> >
> >  - Symbolic links and direct #includes: this was the original approach =
but
> >    was pushed back on from the kernel side, when tooling modified the
> >    headers and broke them accidentally for kernel builds.
> >
> >  - Duplicate self-defined ABI headers like glibc: double the maintenanc=
e
> >    burden, double the chance for mistakes, plus there's no tech-driven
> >    notification mechanism to look at new kernel side changes.
> >
> > What we are doing now is a third option:
> >
> >  - A software-enforced copy-on-write mechanism of kernel headers to
> >    tooling, driven by non-fatal warnings on the tooling side build when
> >    kernel headers get modified:
> >
> >     Warning: Kernel ABI header differences:
> >       diff -u tools/include/uapi/drm/i915_drm.h include/uapi/drm/i915_d=
rm.h
> >       diff -u tools/include/uapi/linux/fs.h include/uapi/linux/fs.h
> >       diff -u tools/include/uapi/linux/kvm.h include/uapi/linux/kvm.h
> >       ...
> >
> >    The tooling policy is to always pick up the kernel side headers as-i=
s,
> >    and integate them into the tooling build. The warnings above serve a=
s a
> >    notification to tooling maintainers that there's changes on the kern=
el
> >    side.
> >
> > We've been using this for many years now, and it might seem hacky, but
> > works surprisingly well.
> >
> > Does this make sense to you?
>
> Yes, although there are probably pieces of the puzzle I'm missing.
> Thanks for the explanation! (That might work almost as-is copied to
> tools/include/uapi/README. ;)
>
> It's also kind of funny to find this kind of back alleys of the kernel
> repo I've never wandered to before.

I have some explanation in the cover letter of the series but I forgot
to mention that in each commit message.  Probably I can update the
explanation with Ingo's reply.

Thanks,
Namhyung