Messages in this thread | | | Date | Mon, 1 Jun 2015 11:35:18 -0400 | From | Paul Gortmaker <> | Subject | Re: [PATCH 10/11] x86: perf_event_intel_bts.c: use arch_initcall to hook in enabling |
| |
On 15-06-01 10:14 AM, Peter Zijlstra wrote: > On Mon, 2015-06-01 at 10:11 -0400, Paul Gortmaker wrote: >> On 15-06-01 03:04 AM, Peter Zijlstra wrote: >>> On Sun, May 31, 2015 at 08:54:11PM -0400, Paul Gortmaker wrote: >>>> This was using module_init, but there is no way this code can >>>> be modular. >>> >>> No, I think you could actually make it modular if you really wanted to. >> >> By "really wanted to" -- do you mean future changes that someone might do? > > Yeah, I think we read "no way this code can be modular" differently. > > I'm reading it like; it can easily be, all it requires is this little > patch, where you're reading it like Kconfig changes.
OK, so how about I update both logs with something like this, to clarify I meant "no way this code can be modular currently, given the existing Kconfig situation":
----------------------8<---------------------------
This was using module_init, but the current Kconfig situation is as follows:
In arch/x86/kernel/cpu/Makefile:
obj-$(CONFIG_CPU_SUP_INTEL) += perf_event_intel_pt.o perf_event_intel_bts.o
and in arch/x86/Kconfig.cpu:
config CPU_SUP_INTEL default y bool "Support Intel processors" if PROCESSOR_SELECT
So currently, the end user can not build this code into a module. If in the future, there is desire for this to be modular, then it can be changed to include <linux/module.h> and use module_init.
But currently, in the non-modular case, a module_init becomes a device_initcall. But this really isn't a device, so we should choose a more appropriate initcall bucket to put it in.
The obvious choice here seems to be arch_initcall, but that does make it earlier than it was currently through device_initcall. As long as perf_pmu_register() is functional, we should be OK.
----------------------8<----------------------------------
Paul.
> >
| |