[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241101213314.GC15112@1wt.eu>
Date: Fri, 1 Nov 2024 22:33:14 +0100
From: Willy Tarreau <w@....eu>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
Shuah Khan <skhan@...uxfoundation.org>, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] nolibc changes for v6.13
Hi Thomas, hi Paul,
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
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.
> 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 :-/
Cheers,
Willy
Powered by blists - more mailing lists