Re: [PATCH 2/7] perf: Create a symlink for a PMU

From: Greg KH <greg@kroah.com>
To: Andi Kleen <ak@linux.intel.com>
Cc: kan.liang@linux.intel.com, peterz@infradead.org,
	mingo@redhat.com, linux-kernel@vger.kernel.org,
	eranian@google.com, namhyung@kernel.org, acme@kernel.org,
	jolsa@redhat.com
Subject: Re: [PATCH 2/7] perf: Create a symlink for a PMU
Date: Thu, 24 Jun 2021 17:31:32 +0200	[thread overview]
Message-ID: <YNSlVPcjHInk4un6@kroah.com> (raw)
In-Reply-To: <1e536604-cf93-0f09-401e-2073924c5582@linux.intel.com>

On Thu, Jun 24, 2021 at 08:24:29AM -0700, Andi Kleen wrote:
> 
> On 6/24/2021 7:29 AM, Greg KH wrote:
> > On Thu, Jun 24, 2021 at 07:24:31AM -0700, Andi Kleen wrote:
> > > > But first off, why is this symlink suddenly needed?  What is so special
> > > > about this new hardware that it breaks the existing model?
> > > The driver can be in two modes:
> > > 
> > > - Driver fully knows the hardware and puts in the correct Linux names
> > > 
> > > - Driver doesn't know the hardware but is in a fallback mode where it only
> > > looks at a discovery table. There we don't have the correct names, just an
> > > numeric identifier for the different hardware sub components.
> > Why does this matter?  Why would the driver not "know" the hardware?  If
> > it doesn't know it, why would it bind to it?
> 
> It's a similar concept as a PCI class. How to have a driver that can handle
> future hardware, but with some restrictions

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.

> The perf CPU PMU has had a similar concept for a long time. The driver can
> be either in architectural mode (with a subset of features), or be fully
> enabled. This allows users who are on an older kernel to still use at least
> a subset of the functionality.

So a device name will move from "generic" to "specific", right?

Why does a bus have to do with any of this?

> > > In the later mode the numeric identifier is used in sysfs, in the former
> > > case the full Linux name. But we want to keep some degree of Linux user
> > > space compatibility between the two, that is why the full mode creates a
> > > symlink from the "numeric" name. This way the (ugly) identifiers needed for
> > > the fallback mode work everywhere.
> > So what _exactly_ does the symlink do here?  What is it from->to?
> 
> It's from numeric identifier to full perf name
> 
> In fallback mode there is no symlink, only the numeric identifier.

Those two sentences do not describe a sysfs path to me.

Where are the Documentation/ABI/ entries for all of this?

> > And where is it being documented?  What userspace tool needs to be fixed
> > up so that the symlink can be removed?
> 
> The names are visible in the perf command lines. Perf supports either name
> without changes. So it's not about fixing a specific tool, but about using
> the drivers in both modes, with limited compatibility between the two.

But a driver does not caer.  And if perf does not care, who cares?

still totally confused,

greg k-h