linux-kernel - Re: [PATCH 1/9] tools/include: Sync uapi/drm/i915

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 9 Apr 2024 09:37:32 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Jani Nikula <jani.nikula@...ux.intel.com>
Cc: Namhyung Kim <namhyung@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...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


* 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?

Thanks,

	Ingo