From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E94578474; Tue, 19 Dec 2023 06:06:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-f169.google.com with SMTP id d2e1a72fcca58-6ce6b62746dso2015259b3a.2; Mon, 18 Dec 2023 22:06:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702966014; x=1703570814; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ZaDSv+Q9/rheu8P6LtF9ghPTerGp6FWZxK2q6v1pYGc=; b=llfJFRAS0nPuaZcctou26In5DhgMmVGAraF0PWHr5uk9eFtL3fiz95/m0QQRbInzru y6C7zsLNADphUN18DzXe/3Yy2fmKkthFEMy6lBTUnm+SiKRbKOZRds2cFCdvAITqvxW3 w+lH2i03qlzPBMMC0NPbKoJBcjK3rDg2KFifv0lIPR0XoNtwotcNNrYNh/k4B0AVk6lh tMZ89J8swqnQ7WX6NREkx8azcrMm1OKOE3ODM90Ab4GtMQYpuWy3xI8tJQSDNDzO2CFH FYuFD1O7ur81xREx6fu1+Q4+B1x4+o3UBsKXqqI4nEvcQ7ls0U6iHoLPsAsPjJ8ZIS80 PKwg== X-Gm-Message-State: AOJu0YzhuO8j1qpeSdDLH3GYwxfdixB6fwyf/bRolVuBVfSy4m7yZnPn 7z/UBrFcVMSoVxo5ywWSuzrOzyvlXwc/79COwMpNwnM44zo= X-Google-Smtp-Source: AGHT+IEVQwJEQZbi+mhOdZfijfrqAW2hEZRhn4eEi/oAmcLANViY/GvVsWxlKeBBtaiCxcwsew2l8ASDMw8HoBA3MYE= X-Received: by 2002:a05:6a00:2352:b0:6d9:3b54:b37a with SMTP id j18-20020a056a00235200b006d93b54b37amr11088pfj.1.1702966014007; Mon, 18 Dec 2023 22:06:54 -0800 (PST) Precedence: bulk X-Mailing-List: linux-perf-users@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20231207011722.1220634-1-irogers@google.com> <20231207011722.1220634-2-irogers@google.com> In-Reply-To: From: Namhyung Kim Date: Mon, 18 Dec 2023 22:06:42 -0800 Message-ID: Subject: Re: [PATCH v6 01/47] perf map: Improve map/unmap parameter names To: Ian Rogers Cc: Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Adrian Hunter , Nick Terrell , Kan Liang , Andi Kleen , Kajol Jain , Athira Rajeev , Huacai Chen , Masami Hiramatsu , Vincent Whitchurch , "Steinar H. Gunderson" , Liam Howlett , Miguel Ojeda , Colin Ian King , Dmitrii Dolgov <9erthalion6@gmail.com>, Yang Jihong , Ming Wang , James Clark , K Prateek Nayak , Sean Christopherson , Leo Yan , Ravi Bangoria , German Gomez , Changbin Du , Paolo Bonzini , Li Dong , Sandipan Das , liuwenyu , linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Guilherme Amadio Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 11, 2023 at 3:52=E2=80=AFPM Ian Rogers wro= te: > > On Mon, Dec 11, 2023 at 3:39=E2=80=AFPM Namhyung Kim wrote: > > > > On Mon, Dec 11, 2023 at 3:38=E2=80=AFPM Namhyung Kim wrote: > > > > > > On Wed, Dec 6, 2023 at 5:17=E2=80=AFPM Ian Rogers wrote: > > > > > > > > The u64 values are either absolute or relative, try to hint better = in > > > > the parameter names. > > > > > > > > Suggested-by: Namhyung Kim > > > > Signed-off-by: Ian Rogers > > > > --- > > > > tools/perf/util/map.h | 16 ++++++++-------- > > > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > > > > > diff --git a/tools/perf/util/map.h b/tools/perf/util/map.h > > > > index 3a3b7757da5f..49756716cb13 100644 > > > > --- a/tools/perf/util/map.h > > > > +++ b/tools/perf/util/map.h > > > > @@ -105,25 +105,25 @@ static inline u64 map__dso_map_ip(const struc= t map *map, u64 ip) > > > > } > > > > > > > > /* dso rip -> ip */ > > > > -static inline u64 map__dso_unmap_ip(const struct map *map, u64 ip) > > > > +static inline u64 map__dso_unmap_ip(const struct map *map, u64 rip= ) > > > > { > > > > - return ip + map__start(map) - map__pgoff(map); > > > > + return rip + map__start(map) - map__pgoff(map); > > > > } > > > > > > > > -static inline u64 map__map_ip(const struct map *map, u64 ip) > > > > +static inline u64 map__map_ip(const struct map *map, u64 ip_or_rip= ) > > > > > > I'm afraid it's gonna be more confusing. Can we say just 'rip'? > > > > Oh.. I think it should be 'ip'. > > But sometimes it is an ip and sometimes it is an rip, hence the long > name. I don't think this really affects much so I'd prefer to stick > with the intention revealing name if possible. I don't think the intention is to mix ip and rip. Does it really pass (already mapped) rip to the map function again? I know rip and ip can be identical but it doesn't mean it can use rip to the map function. Thanks, Namhyung