Re: [PATCH v2 4/4] perf/x86/uncore: modularize Intel uncore driver

["Yan, Zheng" <zheng.z.yan@intel.com>]

On 04/24/2014 04:14 PM, Ingo Molnar wrote:
> 
> * Stephane Eranian <eranian@google.com> wrote:
> 
>>>> Most of the codes without comments are hardware specific codes. 
>>>> The corresponding contents in Intel uncore documents are big 
>>>> tables/lists, nothing tricky/interesting. I really don't know how 
>>>> to comment these code.
>>>
>>> Have a look at other PMU drivers, such as
>>> arch/x86/kernel/cpu/perf_event_intel_rapl.c, which begin with a
>>> general explanation attached below.
>>
>> I think a more useful modularization would be to split that huge 
>> file (perf_event_intel_uncore.c) into smaller files like we do for 
>> the core PMU. There is just too much stuff in this file for my own 
>> taste. Hard to navigate and I spend quite some time looking at it 
>> and modifying it!
>>
>> You could follow the model of the core PMU support files.
>> You'd have a "core" file with the common routines, and then
>> a file perf processor:
>>     - perf_event_intel_uncore.c
>>     - perf_event_intel_snbep_uncore.c
>>     - perf_event_intel_nhmex_uncore.c
>>     - perf_event_intel_ivt_uncore.c
>>     - ...
>>
>> Each processor specific module, would be a kernel module. The core 
>> could be one too. Note that this would not alleviate the need for 
>> some basic descriptions at the beginning of each file outlining the 
>> PMU boxes exported to a minimum.

Most of hardware specific codes in the Intel uncore driver are for SandyBridge/IvyBridge/Haswell. Uncore subsystem in these CPUs are similar. One module per CPU type means we have to duplicate lots of code. I don't think it's a good idea.

Regards
Yan, Zheng

> 
> This structure you outline sounds like a good first step, I like it.
> 
> To simplify this restructuring, initially we could even keep the core 
> uncore bits in the core (ha!), to not have module-on-module 
> dependencies.
> 
> Thanks,
> 
> 	Ingo
>