[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZhV0R1lNRrcOYKkV@x1>
Date: Tue, 9 Apr 2024 14:00:55 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Jani Nikula <jani.nikula@...ux.intel.com>,
Ingo Molnar <mingo@...nel.org>, Ian Rogers <irogers@...gle.com>,
Kan Liang <kan.liang@...ux.intel.com>, Jiri Olsa <jolsa@...nel.org>,
Adrian Hunter <adrian.hunter@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-perf-users@...r.kernel.org,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
David Airlie <airlied@...il.com>, Daniel Vetter <daniel@...ll.ch>,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/9] tools/include: Sync uapi/drm/i915_drm.h with the
kernel sources
On Tue, Apr 09, 2024 at 08:58:55AM -0700, Namhyung Kim wrote:
> Hello,
>
> On Tue, Apr 9, 2024 at 3:14 AM Jani Nikula <jani.nikula@...ux.intel.com> wrote:
> >
> > On Tue, 09 Apr 2024, Ingo Molnar <mingo@...nel.org> wrote:
> > > * Jani Nikula <jani.nikula@...ux.intel.com> wrote:
> > >
> > >> On Mon, 08 Apr 2024, Namhyung Kim <namhyung@...nel.org> wrote:
> > >> > To pick up changes from:
> > >> >
> > >> > b112364867499 ("drm/i915: Add GuC submission interface version query")
> > >> > 5cf0fbf763741 ("drm/i915: Add some boring kerneldoc")
> > >> >
> > >> > This should be used to beautify DRM syscall arguments and it addresses
> > >> > 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 maintenance
> > > 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_drm.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-is,
> > > and integate them into the tooling build. The warnings above serve as a
> > > notification to tooling maintainers that there's changes on the kernel
> > > 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.
I think we can combine Ingo's with the reply I used and you adopted and
continue to have it when sending the update messages, probably keep it
in the cover letter (the combined text) and add a link to each
individual update:
"Please see tools/include/README.kernel-copies."
The recommendation that developers shouldn't update the copy seems
important to have there as well.
- Arnaldo
Powered by blists - more mailing lists