From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D454E155313; Tue, 9 Apr 2024 17:00:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712682058; cv=none; b=KF4i6bieNB8B2Pwb/1QPYWTILQkZVfUM1A//F2tmgbIXi/YR7HtGIwODOPR0guHCuWqZRVft2qMtqz3Mm1n9Gbt2024f6RhWplL3BUpjWVLVhBJULiGsCkJWYzOAoiEA1QuYlqFyOzPlVf9lW223zmkA/30QdijQ8RX+y6SQ5cc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712682058; c=relaxed/simple; bh=4WrtbOs8msag5qvCpx6Nx6EDmYJtha46rksweGE/IUg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ki8m+6gv42S09ECSHGiA7PJ9738QAdGqppWRLr6BGBEF6To8Vu3b8DXVEAZ6uQyreg0d9xifDe6Jm9hLNm2BOJHuMcmY7xAmyMeNqgCWPAk0PIiCkXVtaC3/btNNcqbEpxB9Cy+0KiO4sqx8fQAcaWKHdBS4BGK1GKRIrmH0ObE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MgYtO5Tj; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="MgYtO5Tj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 36113C433B1; Tue, 9 Apr 2024 17:00:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712682058; bh=4WrtbOs8msag5qvCpx6Nx6EDmYJtha46rksweGE/IUg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MgYtO5Tj2EoU/v1AvFrGNp8xJ8FBv7ZUQrP9IrkGf8gFF0Wewc2uyF3jdNxNbApkI Cmi45Fh24KdIDPs+RVXnjEc4VHazHSPw0iCqDakt3IMufLEb0ESclkjlkNCZRg9qjG x6xl5THoYixhoTQej9s12kSr033vdeKGMpb0ErzR0djdcukweuz63kACjq79TJOg0o 9RIDZ316Bec+NnDjBJMwWfBxhcwB/H7QB8cv+0lPQ+Hz9xZsFGJnpyDUrgam6eBPXA vZklfbulNp0Zc0UoORNPGHZjsefhYZk7OQI5/4rqipKXvYabOAKYBiBg2gWK4YlFYG 999SQuF2Bw3Qw== Date: Tue, 9 Apr 2024 14:00:55 -0300 From: Arnaldo Carvalho de Melo To: Namhyung Kim Cc: Jani Nikula , Ingo Molnar , Ian Rogers , Kan Liang , Jiri Olsa , Adrian Hunter , Peter Zijlstra , LKML , linux-perf-users@vger.kernel.org, Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , David Airlie , Daniel Vetter , dri-devel@lists.freedesktop.org Subject: Re: [PATCH 1/9] tools/include: Sync uapi/drm/i915_drm.h with the kernel sources Message-ID: References: <20240408185520.1550865-1-namhyung@kernel.org> <20240408185520.1550865-2-namhyung@kernel.org> <874jcb9etk.fsf@intel.com> <87pluy972m.fsf@intel.com> Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 wrote: > > > > On Tue, 09 Apr 2024, Ingo Molnar wrote: > > > * Jani Nikula wrote: > > > > > >> On Mon, 08 Apr 2024, Namhyung Kim 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