[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YNQckpOuw80uCUa1@kroah.com>
Date: Thu, 24 Jun 2021 07:48:02 +0200
From: Greg KH <greg@...ah.com>
To: kan.liang@...ux.intel.com
Cc: peterz@...radead.org, mingo@...hat.com,
linux-kernel@...r.kernel.org, eranian@...gle.com,
namhyung@...nel.org, acme@...nel.org, jolsa@...hat.com,
ak@...ux.intel.com
Subject: Re: [PATCH 2/7] perf: Create a symlink for a PMU
On Wed, Jun 23, 2021 at 06:22:04PM -0700, kan.liang@...ux.intel.com wrote:
> From: Kan Liang <kan.liang@...ux.intel.com>
>
> A perf PMU may have two PMU names. For example, Intel Sapphire Rapids
> server supports the discovery mechanism. Without the platform-specific
> support, an uncore PMU is named by a type ID plus a box ID, e.g.,
> uncore_type_0_0, because the real name of the uncore PMU cannot be
> retrieved from the discovery table. With the platform-specific support
> later, perf has the mapping information from a type ID to a specific
> uncore unit. Just like the previous platforms, the uncore PMU will be
> named by the real PMU name, e.g., uncore_cha_0. The user scripts which
> work well with the old name may not work anymore. To avoid the issue, a
> symlink should be created from the new to the old name.
>
> The perf PMU devices are created under /sys/bus/event_source/devices/.
> The symlink should be created in the same directory to facilitate the
> perf tool.
>
> Add a new variable, link_name, to store the new name of a PMU. Link it
> to the old name if applies.
Ah, here is the "new name". This needs to be documented.
But first off, why is this symlink suddenly needed? What is so special
about this new hardware that it breaks the existing model?
thanks,
greg k-h
Powered by blists - more mailing lists