Re: [GIT PULL] nolibc changes for v6.13

["Thomas Weißschuh" <linux@weissschuh.net>]

Hi Willy,

On 2024-11-01 22:33:14+0100, Willy Tarreau wrote:
> On Fri, Nov 01, 2024 at 09:23:48PM +0000, Thomas Weißschuh wrote:
> > Hi Paul,
> > 
> > On 2024-11-01 13:22:17-0700, Paul E. McKenney wrote:
> > > On Fri, Nov 01, 2024 at 02:22:13PM +0000, Thomas Weißschuh wrote:
> > > > (resend to add missing Cc: LKML)
> > > > 
> > > > 
> > > > Hi Paul,
> > > > 
> > > > The following changes since commit 9852d85ec9d492ebef56dc5f229416c925758edc:
> > > > 
> > > >   Linux 6.12-rc1 (2024-09-29 15:06:19 -0700)
> > > > 
> > > > are available in the Git repository at:
> > > > 
> > > >   https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git tags/nolibc-20241101-for-6.13-1
> > > > 
> > > > for you to fetch changes up to ad0558f3883130954ca724697f2d19aef93967b3:
> > > > 
> > > >   selftests/nolibc: start qemu with 1 GiB of memory (2024-10-07 21:57:45 +0200)
> > > 
> > > Thank you!  I have pulled this into -rcu at signed tag nolibc.2024.11.01a,
> > > which copies from your signed tag.
> > 
> > Thanks!
> > 
> > > The usual "make run" and "make user" worked fine, but "make libc-test"
> > > gave me the build errors shown below.  Is there some setup step that
> > > I omitted?  Or is this not really a necessary test?
> > 
> > That test does not actually test nolibc but the nolibc test suite.
> > It uses your system libc and makes sure that the nolibc test
> > expectations match the behaviour of a "real" libc.
> > The missing strlcat() function was added to glibc only in 2.38, so I
> > guess you have an older version.
> > On my glibc 2.40 "make libc-test" works and the test itself succeeds.
> > 
> > I'll see if there is a reasonable to make libc-test work on older glibc.
> > But it shouldn't impact this cycle.
> 
> Maybe we could just enclose the test with:
> 
> #if !defined(__GLIBC__) || __GLIBC__ > 2 || __GLIBC_MINOR__ >= 40
>  ...
> #endif

This will mess up the test case numbers.
The test is actually only running on nolibc anyways, so we could also
stub out strlcat() with a dummy inline function.

> The real libc test is indeed not critical but it's important that we try
> to keep it working reasonably well over the long term as it reminds us
> not to diverge too much.

Agreed.

> > For better architecture coverage I would recommend ./run-tests.sh over
> > "make run/user". Speaking about this I remember the discussion from the
> > 6.12 PR where Willy proposed an improved run-tests.sh error message.
> > It seems he didn't push it as a commit, so let's add keep it in mind for
> > next cycle.
> 
> Oups, I vaguely remember proposing a trivial patch in an e-mail a while
> ago but I don't even remember what it was about. My mind is totally taken
> by the upcoming haproxy release these days :-/

It's at https://lore.kernel.org/lkml/ZtlQbpgpn9OQOPyI@1wt.eu/
No worries, I'll pick it up after 6.13-rc1.


Thomas