[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49905050-8bea-498a-9a69-bbf7e00f30c8@t-8ch.de>
Date: Fri, 1 Nov 2024 21:40:34 +0000
From: Thomas Weißschuh <linux@...ssschuh.net>
To: Willy Tarreau <w@....eu>
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 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
Powered by blists - more mailing lists