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 2A5EF2C2374 for ; Sun, 22 Mar 2026 09:06:43 +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=1774170405; cv=none; b=E0gFpDYrk7fBQsSXvxnGLKadp5+l5M4NR8og8f1pIh/MdP02Tr5oRYEYaX1Fg1+DITyxx0OBe/gU5o5U+LfSpm6TRv8Bw9r8ANjkUCC94VIXNstL9/Zi0kSgVr86tpeH7EokYBJ1xtklPA0m9uESRXieNyT8bbf5d0meKkkmw4M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774170405; c=relaxed/simple; bh=zjmAMofLtv+e98L8i/xVNAH97eyM5M+uMPRtHe1jCMU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZQOUzCoU8tz/Y233AycjFqQYMm1lSCGbcLvcOuBhRipDjBuVDU3yj0Wae/1aBeofUy1A/ZdGMyKXMAWYM3faF0iQFrgtb5+w0NPL3PcEi1DjgcwEj8/yBe30vAHOIbfSatUQt7MxpoqBGeKzexU/k7WtScTyoPNzSdemhkywjIE= 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=askg6/SP; 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="askg6/SP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1wt.eu; s=mail; t=1774170402; bh=khqDUnw9Ijm/rMEkhq9PoqH/z5zGdeaCUvrd0zH7ri8=; h=From:Message-ID:From; b=askg6/SPxkbVcsaSlXX0sTr2SiSqznilTtfucJ7knQhUnLVW6S54iZDqNz+agqPrJ r+8KvbslHx4IsmXjMoiVtr7Ev8/d67rkiWqHWBb8ltys7IRxiPVlGrhj+0U0wTiJeS ZJBitTBb/I377npr7i8UVKwpEyripU2oEmPivMwk= Received: from 1wt.eu (ded1.1wt.eu [163.172.96.212]) by mta1.formilux.org (Postfix) with ESMTP id 639A5C0A54; Sun, 22 Mar 2026 10:06:42 +0100 (CET) Date: Sun, 22 Mar 2026 10:06:42 +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> 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: <20260319-nolibc-namespacing-v1-1-33c22eaddb5e@weissschuh.net> Hi Thomas, 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. > Avoid these conflicts by using an leading underscore which moves the > names into the implementation's namespace. This naming scheme was chosen > over a '__nolibc_' prefix, as these functions are not an implementation > detail but a documented interface meant to be used by applications. Agreed. > While this may break some existing users, adapting them should be > straightforward. Given that nolibc is most-likely vendored, no > unexpected breakage should happen. No in-tree users are affected. I also checked in my local stuff (preinit, watchdog daemon etc) and didn't find any user of sys_*. > 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. > Signed-off-by: Thomas Weißschuh > --- > I am not really thrilled about breaking these names. > But every other option seems to be horribly to maintain > or will break sooner or later anyways. > Any ideas? I think your approach is reasonable for the reasons you explained. Yes we do want to continue to export these, and they're not supposed to be spread all over application code, so changes if any should be very limited. So: Acked-by: Willy Tarreau 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. Cheers, Willy