From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 34FECC49EA7 for ; Fri, 25 Jun 2021 14:49:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1E2496161C for ; Fri, 25 Jun 2021 14:49:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231847AbhFYOv7 (ORCPT ); Fri, 25 Jun 2021 10:51:59 -0400 Received: from mga17.intel.com ([192.55.52.151]:37215 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229653AbhFYOv6 (ORCPT ); Fri, 25 Jun 2021 10:51:58 -0400 IronPort-SDR: KV8xG4BHhN5xpoPjl5UW3ysmV+JBHiyHDsSMB0aKSC4jfG2gz8nrcdAG5DWF4d8sv3NAHySmoT meIOs6uwLJRg== X-IronPort-AV: E=McAfee;i="6200,9189,10026"; a="188063324" X-IronPort-AV: E=Sophos;i="5.83,299,1616482800"; d="scan'208";a="188063324" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2021 07:49:37 -0700 IronPort-SDR: xRNmGZ16A0y4EtE2kDvY9yuKIaJViN3e4VeN9K2AyzaJivMjOg/hLj7o0G4HRZ53PBEC3Er6Gp Hfwm64jnCLmQ== X-IronPort-AV: E=Sophos;i="5.83,299,1616482800"; d="scan'208";a="488207947" Received: from akleen-mobl1.amr.corp.intel.com (HELO [10.209.62.195]) ([10.209.62.195]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Jun 2021 07:49:37 -0700 Subject: Re: [PATCH 2/7] perf: Create a symlink for a PMU To: Greg KH 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 References: <1624497729-158864-1-git-send-email-kan.liang@linux.intel.com> <1624497729-158864-3-git-send-email-kan.liang@linux.intel.com> <1e536604-cf93-0f09-401e-2073924c5582@linux.intel.com> <29d5f315-578f-103c-9523-ae890e29c7e7@linux.intel.com> <540d8a38-da12-56c8-8306-8d3d61ae1d6b@linux.intel.com> From: Andi Kleen Message-ID: Date: Fri, 25 Jun 2021 07:49:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Device names will change, that's always a given, as the kernel can never > always make them the same. That's why userspace needs to scan the bus > for all devices and then pick out the one that it wants to look at. In perf the tool doesn't normally know what devices (= pmu) the users want to look at. It's all specified on the command line depending on what events you want to measure. There's no way for the tool to figure that out on its own. > Don't hard-encode device names into userspace tools, that way lies > madness. There's no hard coding in the tools (or at least not for the non json event list case). It all comes from the command line. But that is where the problem comes from. > >> 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? > Do not have 2 different structures represent the same hardware device, > that too is a shortcut to madness. > > What prevents userspace from handling device names changing today? Why > are you forcing userspace to pick a specific device name at all? The way the perf tool works is that you have to specify the names on the command line: perf stat -a -e uncore_cha/event=1/ ... With the numeric identifiers it would be perf stat -a -e uncore_type_X_Y/event=1/ The tool handles it all abstractly. So yes the user tools itself can handle it. But the problem is that it is directly exposed to the users, so the users would need to change all their scripts when switching between the two cases. That is what we're trying to avoid -- provide them a way that works on both. -Andi