Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp267735pxv; Thu, 24 Jun 2021 07:31:44 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzn+4JdoSGS+3ap6oT4dQ7HRONh69eOF6NwF+t2IzRGeTlAhjLs3z2QbxoXaXqLtOQ6ETjJ X-Received: by 2002:a17:906:1313:: with SMTP id w19mr5733402ejb.178.1624545104312; Thu, 24 Jun 2021 07:31:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624545104; cv=none; d=google.com; s=arc-20160816; b=IL16G78GUwzqh1r4sNh3ZMDqE4VvfxNZjWc/KB3Rub4OpiBU3Ba1ZNQkOZa4i2Zbsm H5BQljIaJUGg49JP9oNHVkS1+mYXFT7I4O5/EIDL34T9RSPkT+bBQj+Zpjh/g4JU/Piu dSWUl4TujgPmVU+EvGRH3FSrsSldT1Yyy1Rz8G3DLlDqAu/Z5HeWN36Q7jA4jOITtEg/ ggpDx38i43qjQptSTDkC0PK0H2aDkklx9ruwItEL5c+0EIYugxeGtmcjYR/x2Nv3xoSo t2BLJmbFVVxP1hCoqx72U6AQ83omDwKBoiMvff7DoQct8eakr8eF9pcIkxcJ6ioGSf9q jVIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=FXFoqCBFeCNMlb7IjGBpYzK+n/QQU4EAIyRrm0cbZaw=; b=LzP4rdopV32/QS3VrG1dHVI7AP07XD6JIzZe4sy6hjBq2UpOePQuID7HXYLLQDTR5i LfWzuE9Us6pPxVskFNmtl2do6bUFUxz7RU5YY/MsYYwyLD/HCEWUf4U5QGtG5DnQbayt aj9QNW7MgN+bGr/2Fe5Ix/oHQ36408+DaPvU/CbTmgfgvlkQ9s1fSxVYvMlNjYRY6A4/ oKEwTOIMjb9RZm/NXWTPMmRwjYKBi+SiGxojmKnXtjCYsb40jaNjpXyEvobCwvj/T1VI RgHlkiv802sReMJ53OA2mIa2G7CN3lf191ViO1yqg/xQvfoZrOvwKKim9Ygq4CrJAOm4 4ZVg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kroah.com header.s=fm1 header.b=DYR2k9zJ; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=cDsGnemm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w21si2794567ejk.639.2021.06.24.07.31.21; Thu, 24 Jun 2021 07:31:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kroah.com header.s=fm1 header.b=DYR2k9zJ; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=cDsGnemm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231475AbhFXObc (ORCPT + 99 others); Thu, 24 Jun 2021 10:31:32 -0400 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]:35037 "EHLO wnew1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230008AbhFXObc (ORCPT ); Thu, 24 Jun 2021 10:31:32 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.west.internal (Postfix) with ESMTP id C109F2B01232; Thu, 24 Jun 2021 10:29:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Thu, 24 Jun 2021 10:29:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm1; bh=FXFoqCBFeCNMlb7IjGBpYzK+n/Q QU4EAIyRrm0cbZaw=; b=DYR2k9zJgHdZL8P0amaOkkyfbSTCeUoJLms3qUhZANY NT9MN112Yifl9W/JjPA0u72YGHTRFBdUGBD2tPnAQyg82XyTYloPKjb0xHc7R6AO D1zEO4aFMaVhxvXQ2gWJmCdaHgGQ1cJSlhk4xyTAf1NUwr25KhveoDFv/NEi1KuQ /4wQdNu/h0bJkBF6Ij6Mn0480oJcOVE+60NI7hzjA9E86iKi+oOXafZktZyAAqX8 9lwGbi4WFtxueqQMjv6+k1aOmP6QtH2ktIGgIruCpI0fCWCcr3Hz9UI8itdVJKat t+jPTyTGY4PvoEgvbyOuBzgf0XVp8QODeXqK14xK+tA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=FXFoqC BFeCNMlb7IjGBpYzK+n/QQU4EAIyRrm0cbZaw=; b=cDsGnemmJiQFSY64OQyk4C oEAk31StoSzXFgDvXS1dSj6hlEr+vC/Q+3S7dhr3yM8pf2VJlwyoabkCIEe8FrD+ xd1Ys6xH1vqfJVNZce9g7JlkpeyC9ix2f7nd0QnuJehH2JPa5dCWaliNsnRzOGIW xOKU/hwiVXVt8r0D9MAoa3+/nadJXeA9J6aaJ/ntSuHZ30XXRGkUgjEfrU2MLe2n ZNK07TxvSB37jk2LJseA+ngt/8hpC/CnqME9XgFbPxGnLPh0rfuAIUOmgEAk45pO aFA8ENqJGnIjXYn1UfZg9HztrArSXiJe8kN2GtVfaAEPeC4Y+UiiT5EPYqwrJDdw == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrfeeghedgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpefirhgvghcu mffjuceoghhrvghgsehkrhhorghhrdgtohhmqeenucggtffrrghtthgvrhhnpeevueehje fgfffgiedvudekvdektdelleelgefhleejieeugeegveeuuddukedvteenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhrohgrhh drtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 24 Jun 2021 10:29:10 -0400 (EDT) Date: Thu, 24 Jun 2021 16:29:08 +0200 From: Greg KH To: Andi Kleen 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 Message-ID: References: <1624497729-158864-1-git-send-email-kan.liang@linux.intel.com> <1624497729-158864-3-git-send-email-kan.liang@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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? And where is it being documented? What userspace tool needs to be fixed up so that the symlink can be removed? thanks, greg k-h