From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 2A9E6221703 for ; Wed, 5 Nov 2025 19:41:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762371666; cv=none; b=s1Bz0TNNzdr6ZR46bd6lgMRzermgwgL8FmKTFGBX3wmP5slivlPYo2oQY99kpjJKO6BXs+fbqIiqquQ+UWBiJFis8pGYM8XjYeJGkZO0YmivxrTI9fGaECwLjEMEkNmVX0TFbk5LcLjK/oUEzc09u0ZbzLF2E3pUhyDF3OflvyM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762371666; c=relaxed/simple; bh=C5B9GxGKynn/bGUHoRkkgvCg0pIh/B+Fhjizl4WzJJk=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=JWopnf907fvbqjveJlGNcuuKrddw3R6o0INPyKU8F0KgsGGgVTRofy0BRpZri3QM0FtPCjrQRntehjsj59PmqpZ1Kx1XtVHa9KH1gt1cH6GeiG7FGzklPiUYdLjaPtiNWovdpaF69IGga8v+OT48SmH+1Dad3vXP5D0SPutjCXk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=iuha9v5z; arc=none smtp.client-ip=209.85.216.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="iuha9v5z" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-339d7c4039aso298447a91.0 for ; Wed, 05 Nov 2025 11:41:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762371664; x=1762976464; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=C5B9GxGKynn/bGUHoRkkgvCg0pIh/B+Fhjizl4WzJJk=; b=iuha9v5zBNFWYaSMXmyzZW+Mvr7qqeqpNEa34QQvaNRuSUC8Qcd/B43jY/zfpPdm0U VeKgpXsUpSpmMGLCDDYKJyPTESOeVLSU2oGWYC/dZAelJRTooKHOMpiktegfWtBQtGo/ Yhk/NuxbFS3aIToRflOHpGKUVLgIckdVYGdpB5tIIEjGX3EnD7PK+yjVdZUhPkBFJxl3 Eb9IwGvllFMNFwZiZI8H79E3O5aquGVCoGCjiEkTah4s+icqAVFtwd8pgfkca1G4Ji7e vcbevePC+eNg+f4c3WMrDJgt1To2d7QfRdR3pXosERZyg0Nrlp3jPPfJvb1MaKqEFEvO Jxgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762371664; x=1762976464; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=C5B9GxGKynn/bGUHoRkkgvCg0pIh/B+Fhjizl4WzJJk=; b=nA/ikvrcxRcyTVjaRMdqabo/PnJXVC9EvWxa2qqj/Su6RAupn26TUvl8l347eF/Nui wGYIsawMaxFZfyjiRhdz5D2lxUrk/wHGL4o7huhZEuSYsa+IxXnoOZ5Y6kLaXGsTCESX KPhOy/wEUWIKJtfQgQylFNGWL62ijg1sZAF+dvG8+t1VLiJF85HoZzIjGyoTvS45gDwQ SqA/viTlkyYyVAr4yyjXoQPBpRRdaCxYi8DA367relvpmBPJVF7BzO7luwvcyhlaAOeA 6Px2/VhorsVkZ0r/77kkvcBK54H+nuOptfSovUlQOyuIf4MaOQlzO1yJP7ifONCMZyn9 nGYA== X-Forwarded-Encrypted: i=1; AJvYcCXRWXFbph7umQtelSbM4nhzBRT1UqVorjsMXkYqd/yJSRnqk0obgJDSA66iiS6vBcPXcudjHUIE6vic7ZE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzmyrh5/Coa/D54X4KLcnQrUzMBFgkmoZUU/XDVNEh4UuA8jQjT AYfWoIKqR8Km8VxREugtYhltmGi/ijNMwnQ5tWOPCZaWRGm0fAIwztxPqXzaSfaO X-Gm-Gg: ASbGncsfxMGat89H66iWLElm3Gvex87fGeCTfydgoJVT9RCn4LhlPv8njdfChLJJvhM /NGucZY+L49imFLbvin4kNjZ+c6u75nRaTziH/sSTcSNBSfM8MaYcdBkckf3lI2GoRBnHY4hfyG ITKskb8GTX9SuhZEiXfSydX9t2QNOlvIz6XdNbfFetXqBCqeSSE4K/Ja26Pnmy1LDm2SgXafboX K2Q/Bd9JPpI+lpTVpr9Q/iT7sg2FIBAnS2AIuNXSaGl6tJ+0KwybdgLDvav+342SHPGqQM02EGy xwOeT0+hvtIFztN5u/Birnxp6WUgcZ1GUTpO4F8Ryma1wMD3bIsbPqxapMxo7Kd3rDHha6oEMjk 9SH8rlerZSh1GzAxQFwHJ+rGSyd7IHKVVG46kF2WSLirz4N26M3lAOzfCnEn+COoWVOJYH7IC1q EOqkRgZYdOi2iV/ZQz6Eyg7ya5 X-Google-Smtp-Source: AGHT+IFlDfByK8EQR3VsU/N7Fktp4sRb4vaWqlmdg9izLxvSHW9VykP1tI0nh0Yuf2migfAoNWhLFw== X-Received: by 2002:a17:903:19cc:b0:269:aba0:f0a7 with SMTP id d9443c01a7336-2962adb32acmr61556695ad.2.1762371664315; Wed, 05 Nov 2025 11:41:04 -0800 (PST) Received: from ?IPv6:2a03:83e0:115c:1:cdf2:29c1:f331:3e1? ([2620:10d:c090:500::6:8aee]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29650c5d0c1sm3413535ad.27.2025.11.05.11.41.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Nov 2025 11:41:03 -0800 (PST) Message-ID: <7f3586157e17d0ab2c34b16d2f7daf4955d0692f.camel@gmail.com> Subject: Re: [RFC PATCH v4 1/7] libbpf: Extract BTF type remapping logic into helper function From: Eduard Zingerman To: Andrii Nakryiko Cc: Donglin Peng , ast@kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, Alan Maguire , Song Liu , pengdonglin Date: Wed, 05 Nov 2025 11:41:02 -0800 In-Reply-To: References: <20251104134033.344807-1-dolinux.peng@gmail.com> <20251104134033.344807-2-dolinux.peng@gmail.com> <61e92756ea7f202f2e501747b574e97b2f5bc32f.camel@gmail.com> <61f94d36d6777b9b84e9bf865edd17476a278e73.camel@gmail.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2025-11-05 at 10:20 -0800, Andrii Nakryiko wrote: [...] > You don't like that I ask people to improve implementation? Not at all. > You don't like the implementation itself? Or are you suggesting that > we should add a "generic" C implementation of > lower_bound/upper_bound and use callbacks for comparison logic? What > are you ranting about, exactly? Actually, having it as a static inline function in a header would be nice. I just tried that, and gcc is perfectly capable of inlining the comparison function in -O2 mode. I'm ranting about patch #5 being 101 insertions(+), 10 deletions(-) and patch #4 being 119 insertions(+), 23 deletions(-), while doing exactly the same thing. And yes, this copy of binary search routine probably won't ever change. But changes to the comparator logic are pretty much possible, if we decide to include 'kind' as a secondary key one day. And that change will have to happen twice. > As I said, once binary search (of whatever kind, bounds or exact) is > written for something like this, it doesn't have to ever be modified. > I don't see this as a maintainability hurdle at all. But sharing code > between libbpf and kernel is something to be avoided. Look at #ifdef > __KERNEL__ sections of relo_core.c as one reason why.