From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.formilux.org (mta1.formilux.org [51.159.59.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7C98C226D02 for ; Sun, 22 Mar 2026 11:03:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=51.159.59.229 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774177415; cv=none; b=i+83Y+rbcnlZLCegX10r74ZA+6JiaHboDG2SFBQUUOwhWOpwCBZ1Prg80SPqrvAakfcR0XgFRAyoY91MHLwApzLMPNn8DJrt2u/UYbusC4mqnDJFss6+pDLSdQfb6wtG3sIGT++Un2Rlt7ZxNABO3WlYq7cjCf4EjPqO+yXOVNk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774177415; c=relaxed/simple; bh=uVJ/QS6UcMSue+iTzetR4j0ooQDBP8U0rtl1YVHHb7I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=HKbsj6w2hNBA5AuejPGCtUCIY8eMo7co5QxZf2zCkDrYp+AtBaQPZEf5epqs/k/pIaq43/ANJK1e6vOxymXrJlbHt2xzsGxCt/p3pM5sqK80pnyo50O8k3gLCK4k/KZ1z4I+AFq27wnWGw8SiFYET0zC7VVPEdENl5d4FyiHTo4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu; spf=pass smtp.mailfrom=1wt.eu; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b=u/gggiCP; arc=none smtp.client-ip=51.159.59.229 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=1wt.eu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=1wt.eu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=1wt.eu header.i=@1wt.eu header.b="u/gggiCP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1774177410; bh=Wp3kKM56DoDjdVbywIcLV6EWn+H4gV6JUOFQm6L33Gk=; h=From:Message-ID:From; b=u/gggiCPFTycyym8X4LFB37mWMxSB1AQPW7d8LmmvOmrbUMj25IztWZO6e4WXqABX lnXo37VuOACSOgVH+rDHNU/mLUrP6SVWu7RGFNJWV8GvarL2kmq6eVamSmnM0voAKq 4lJbe6RLeIu+W0yz/407gGT3b1CV5xmD2AeCujoQ= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 87990C0A41; Sun, 22 Mar 2026 12:03:30 +0100 (CET) Date: Sun, 22 Mar 2026 12:03:30 +0100 From: Willy Tarreau To: Thomas =?iso-8859-1?Q?Wei=DFschuh?= Cc: linux-kernel@vger.kernel.org Subject: Re: [PATCH] tools/nolibc: rename sys_foo() functions to _sys_foo() Message-ID: References: <20260319-nolibc-namespacing-v1-1-33c22eaddb5e@weissschuh.net> <9b30e65c-2ee8-4f0a-b4b9-a48a0964e586@t-8ch.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9b30e65c-2ee8-4f0a-b4b9-a48a0964e586@t-8ch.de> On Sun, Mar 22, 2026 at 11:43:56AM +0100, Thomas Weißschuh wrote: > On 2026-03-22 10:06:42+0100, Willy Tarreau wrote: > > On Thu, Mar 19, 2026 at 05:20:17PM +0100, Thomas Weißschuh wrote: > > > The sys_foo() naming scheme used by the syscall wrappers may collide > > > with application symbols. Especially as 'sys_' is an obvious naming > > > scheme an application may choose for its own custom systemcall wrappers. > > > > Yes but on the other hand it might implement it when missing the one > > offered by the libc. > > I don't really get this sentence. Do you refer to the '#ifdef sys_foo' > as you mention below? Ah no, but rereading my message shows me it was not really parsable :-) I meant that some applications missing a syscall in nolibc (and detecting this miss via any method) could decide to implement their own equivalent for the time it takes to integrate the feature into nolibc, and thus it can make sense that they call their feature sys_foo like we do, so that their sys_foo is basically the same as ours (i.e. they really just have to detect the conflict one way or another but that's all). > > > These conflicts happen when compiling some of the kernel selftests > > > with nolibc. > > > > You mean some of the syscall entry points ? If so, I'm seeing one > > exception of _sys_rt_sigreturn(), not convinced it could be an issue > > though. > > Not the syscall entrypoints, these are internal to the kernel. That's why it surprised me ;-) > Some selftests bypass libc (for various, legitimate reasons) and > directly call the syscalls. They tend to name their wrappers > 'sys_foo()'. > > See for example these: > * tools/testing/selftests/vDSO/vdso_test_correctness.c > * tools/testing/selftests/bpf/bpf_util.h > * tools/testing/selftests/bpf/task_local_storage_helpers.h > * tools/testing/selftests/rseq/param_test.c Ah OK! That totally makes sense. > Thanks! And pushed to the git tree. Thank you! > > On a related topic, I've been thinking several times about how to discover > > support or not of a syscall in nolibc by the application, especially since > > the lib improves fast and applications might not want to wait for it to > > support a new syscall, and end up with their own as you suggested above. > > Maybe this _sys_foo thing could be the opportunity for us to generalize > > the systematic addition of: > > > > #define _sys_foo _sys_foo > > > > before every definition, so that application can simply use #ifndef to > > define their own local version. There's no emergency, it's been that way > > for years, I'm sharing it just as food for thought. > > I am not sure about that. > > In the most common case, where the version of nolibc is locked, > the local version would either be used all the time or never. > So any ifdeffery would only make the code harder to read. > Even if a user really needs to handle different versions of nolibc, > in my opinion they should just always use their custom code to make > sure to keep the behavior predictable. In fact it's not about handling different versions, it's really about working around what's missing. I face this every day as a userland developer. As soon as you depend on a lib, you figure something is missing, and you cannot stop your project because of this. So the right thing to do is to implement what you're missing in a mostly discoverable way, and the try to upstream your work into the lib that was missing the feature. Inside the kernel, this problem is less visible because it's the same repository, so anyone working on their selftest etc can also directly commit into the nolibc subdir as well. When you're using code outside it's totally different, as you have less control over the selection of kernel headers version, hence nolibc version. I personally don't think that a single define in front of each syscall definition will make the code harder to read. It can be argued that glibc doesn't offer this and that the user application will have to compose with all of this, however glibc offers lots more stuff than we do, and users rely on its version to guess whether or not something is present, which is something we don't really have. Willy