Some points to mention here. This patch set actually introduces twointerfaces, a new user/kernel interface and an in-kernel api to accessperformance counters. These are separate things and sometimes mixedtoo much. There is a strong need for an in-kernel api. This is thethird implementation I am involved (oprofile, perfmon are the others)and the things are always the same way. All these subsystems should bemerged to one in-kernel implemenation and share the same code. Thedifferent user/kernel i/fs could then coexist and meet the usersdifferent needs.The implementation of the hardware counters is written from scratchagain. It is sometimes useful to drop old code, but there is thedanger of making errors twice. Implementing performance counters isnot trivial, especially buffer handling, SMP and cpu hotplug. Foroprofile and perfmon it took years to get stable code. We shouldbenefit from this. (The current x86 code in this patch series seemsnot to work proper with SMP.) So we should look for a way to betterreuse and share code.

I would like to define _all_ the behaviour of the architecture and themodels in functions instead of parameters and lists. It is hard toexplain why, because it is more esthetics, but I believe, only nicethings work best. Let me try.

1) The list above seems to be random, there are lots of events and itis hard to define, which event is really important. Surely theseevents are important, but it is hard to draw a line here.

2) The list assumes/implies the events are available on allarchitectures and cpus. This is probably not the case, and also, theexistence of an event must not be _important_ for a certainarchitecture. But it has to be there even if it is of no interest.

3) Hard to extend. If an event is added here this could have impact toall other architectures. Data structures are changing.

4) In the kernel the behaviour of a subsystem is offen implemented byfunctions (e.g. struct device_driver). There are lots of ops structsin the kernel and there are reasons for it.

5) ops structs are more dynamic. The data could be generateddynamically and does not have to be static in some tables andvariables.

So, instead of making the list a public data structure, better passthe type to an arch specific function, e.g.:

int arch_xxx_setup_event(int event_type);

If the type is not supported, an error could be returned. There is nomore impact. Even the binaries of the builds would be identically ifhw_event_types would be extended for a single different architecture.

The same applies also for counters and so on, better implementfunctions.