Received-SPF: pass (google.com: domain of linux-kernel+bounces-136660-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Jani Nikula <jani.nikula@linux.intel.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Namhyung Kim <namhyung@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
Subject: Re: [PATCH 1/9] tools/include: Sync uapi/drm/i915_drm.h with the
 kernel sources
In-Reply-To: <ZhTwPLliHXKPAJUQ@gmail.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
References: <20240408185520.1550865-1-namhyung@kernel.org>
 <20240408185520.1550865-2-namhyung@kernel.org> <874jcb9etk.fsf@intel.com>
 <ZhTwPLliHXKPAJUQ@gmail.com>
Date: Tue, 09 Apr 2024 13:14:09 +0300
Message-ID: <87pluy972m.fsf@intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

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 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.

BR,
Jani.

-- 
Jani Nikula, Intel