On 04/24/2014 04:14 PM, Ingo Molnar wrote: > > * Stephane Eranian <eran...@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 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
