[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <540d8a38-da12-56c8-8306-8d3d61ae1d6b@linux.intel.com>
Date: Fri, 25 Jun 2021 07:22:08 -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
On 6/24/2021 10:19 PM, Greg KH wrote:
> On Thu, Jun 24, 2021 at 10:28:36AM -0700, Andi Kleen wrote:
>>> 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.
> Great, then as you have deemed the device name part of your documented
> api, then keep it stable as that is what you decided to do a long time
> ago when it was created.
The fully supported driver keeps it stable, but the driver in fallback
mode (as in running on a yet unknown system) can't because it doesn't
have enough information. It has to fall back to the numeric identifiers.
Supporting yet unknown systems is a big advantage, missing full kernel
support is the number one reason people can't use uncore monitoring today.
The symlink keeps some degree of compatibility between the two.
Anyways thinking about it if Greg doesn't want symlinks (even though
sysfs already has symlinks elsewhere), maybe we could just create two
devices without symlinks. Kan, do you think that would work?
-Andi
Powered by blists - more mailing lists