[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <29d5f315-578f-103c-9523-ae890e29c7e7@linux.intel.com>
Date: Thu, 24 Jun 2021 10:28:36 -0700
From: Andi Kleen <ak@...ux.intel.com>
To: Greg KH <greg@...ah.com>
Cc: kan.liang@...ux.intel.com, peterz@...radead.org, mingo@...hat.com,
linux-kernel@...r.kernel.org, eranian@...gle.com,
namhyung@...nel.org, acme@...nel.org, jolsa@...hat.com
Subject: Re: [PATCH 2/7] perf: Create a symlink for a PMU
> But this is NOT how busses work in the driver model.
>
> PCI classes are great, but we do NOT suddenly add a symlink in sysfs if
> a driver goes from being handled by "generic_pci_type_foo" to
> "vendor_foo". Userspace can handle the change and life goes on.
In perf this is exposed to the user command line, and lots of people
configure their own events, so it's very common in scripts. To use the
pmu you have to use something like perf stat -a -e uncore_foo/.../. So
it's not a single thing that could be patched up.
The perf tools supports PMUs abstractly and doesn't have special
handling for every PMU. Also the perf design was always that the kernel
should provide these abstractions with the user tool being (mostly)
generic and abstract.
> So a device name will move from "generic" to "specific", right?
>
> Why does a bus have to do with any of this?
The perf pmus are in /sys/devices, so the symlinks for compatibility
have to be created there.
> But a driver does not caer. And if perf does not care, who cares?
The users who write scripts that specify the perf events on the perf
command line.
-Andi
Powered by blists - more mailing lists