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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YNTCa5QO1YMy8fJ0@kroah.com>
Date:   Thu, 24 Jun 2021 19:35:39 +0200
From:   Greg KH <greg@...ah.com>
To:     "Liang, Kan" <kan.liang@...ux.intel.com>
Cc:     Andi Kleen <ak@...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 Thu, Jun 24, 2021 at 01:07:14PM -0400, Liang, Kan wrote:
> 
> 
> On 6/24/2021 11:31 AM, Greg KH wrote:
> > 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?
> 
> We'd like to keep both names.

That is not how sysfs and the driver model works, sorry.  You don't get
to keep both names, otherwise sysfs would be even more of a mess than it
currently is.  What happens if you need "another" name in the future?
When do you stop?

this isn't ok, please do it right.

greg k-h