[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <480f6bf5-20ea-47a0-a1be-3f3cf15227b6@zytor.com>
Date: Wed, 30 Apr 2025 10:34:42 -0700
From: Xin Li <xin@...or.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: LKML <linux-kernel@...r.kernel.org>, kvm@...r.kernel.org,
linux-perf-users@...r.kernel.org, linux-hyperv@...r.kernel.org,
virtualization@...ts.linux.dev, linux-pm@...r.kernel.org,
linux-edac@...r.kernel.org, xen-devel@...ts.xenproject.org,
linux-acpi@...r.kernel.org, linux-hwmon@...r.kernel.org,
Netdev <netdev@...r.kernel.org>, platform-driver-x86@...r.kernel.org,
tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
acme@...nel.org, jgross@...e.com, andrew.cooper3@...rix.com,
peterz@...radead.org, namhyung@...nel.org, mark.rutland@....com,
alexander.shishkin@...ux.intel.com, jolsa@...nel.org,
irogers@...gle.com, adrian.hunter@...el.com, kan.liang@...ux.intel.com,
wei.liu@...nel.org, ajay.kaher@...adcom.com,
bcm-kernel-feedback-list@...adcom.com, tony.luck@...el.com,
pbonzini@...hat.com, vkuznets@...hat.com, seanjc@...gle.com,
luto@...nel.org, boris.ostrovsky@...cle.com, kys@...rosoft.com,
haiyangz@...rosoft.com, decui@...rosoft.com,
dapeng1.mi@...ux.intel.com
Subject: Re: [PATCH v4 01/15] x86/msr: Add missing includes of <asm/msr.h>
On 4/30/2025 2:17 AM, Ilpo Järvinen wrote:
> While this is not my subsystem so don't have the final say here, you had
> to explain quite much to prove that (and reviewer would have to go through
> the same places to check). Wouldn't it be much simpler for all if all
> those .c files would just include <asm/msr.h> directly? No need to explain
> anything then.
>
> Also, similar to what you're doing for some tsc related things in this
> series, somebody could in the future decide that hey, these static inline
> functions (that use .*msr.*) belong to some other file, allowing msr.h to
> be removed from arch/x86/events/perf_event.h. Again, we'd need to add
> asm/msr.h into more .c files. This is the problem with relying on indirect
> includes, they create hard to track dependencies for #includes done in .h
> files. If we actively encourage to depend on indirect #include
> dependencies like that, it makes it very hard to_remove_ any #include
> from a header file (as you have yourself discovered).
You're right, it makes a lot of sense from maintenance point of view.
Powered by blists - more mailing lists