[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <df5de815-ad91-4ab5-beca-01714294b405@paulmck-laptop>
Date: Mon, 16 Oct 2023 15:56:03 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: Willy Tarreau <w@....eu>, Zhangjin Wu <falcon@...ylab.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/nolibc: add tests for multi-object linkage
On Tue, Oct 17, 2023 at 12:03:41AM +0200, Thomas Weißschuh wrote:
> On 2023-10-16 09:24:19-0700, Paul E. McKenney wrote:
> > On Thu, Oct 12, 2023 at 01:18:18PM -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 12, 2023 at 09:34:53PM +0200, Thomas Weißschuh wrote:
> > > > On 2023-10-12 12:06:33-0700, Paul E. McKenney wrote:
> > > > > On Thu, Oct 12, 2023 at 08:39:14PM +0200, Thomas Weißschuh wrote:
> > > > > > On 2023-10-12 11:25:02-0700, Paul E. McKenney wrote:
> > > > > > > [..]
> > > >
> > > > > > > I have a signed tag urgent/nolibc.2023.10.12a in the -rcu tree, so
> > > > > > > please check the lead-in text for sanity. (Everything after the digital
> > > > > > > signature is automatically generated.)
> > > > > >
> > > > > > Looks good. But it's only a listing of the commit subjects, correct?
> > > > >
> > > > > Pretty close, just a few added words on the last one.
> > > > >
> > > > > So the question is whether there is some larger issue that Linus should
> > > > > be made aware of. If these are just simple fixes for simple bugs,
> > > > > we should be good, but yes, I do need to ask. ;-)
> > > >
> > > > These are simple fixes for simple bugs.
> > > >
> > > > Do you always have to ask specifically or can I just mention it in the
> > > > pull request in the future?
> > >
> > > I would be extremely happy to simply copy text from the pull request
> > > into the signed tags. ;-)
> > >
> > > We would just need to agree on the format. For example, in this case,
> > > there will eventually be two signed tags, one for the urgent pull
> > > request early next week and another for the pull request for the upcoming
> > > merge window.
> > >
> > > Proposals for the format?
> >
> > Actually, proposals for the signed-tag text for the urgent commits?
> > Left to myself, I would use the same text shown below that I proposed
> > last week.
>
> Looks good.
>
> The tags for urgent PRs seem good with one item per patch.
You got it! urgent/nolibc.2023.10.16a
> I guess for normal PRs one item per series would be fine.
That makes a lot of sense -- with a non-urgent series, there should be
some sort of development theme. I immediately see the list shown below.
Please let me know of any needed adjustments.
Thanx, Paul
------------------------------------------------------------------------
Add stdarg.h.
Optimize x86 string functions and remove unused internal functions.
Adjust compiler flags to avoid accidental reliance on system header files,
to avoid false-positive warnings, and to allow building 32-bit i386 with
multi-architecture compilers.
Pass initrd to qemu separately from the kernel image to avoid needless
kernel relinks. Make ppc64le use qemu-system-ppc64 in order to provide
bi-endian support.
Create varargs __nolibc_enosys() function to avoid false-positive
compiler warnings for unimplemented system calls. Rely on kernel
system-call-number definitions to avoid breaking common-code userspace.
Automatrically determine whether pselect6() is required to avoid a bit of
manual coding. Add support for C-language constructors and destructors.
Drop redundant tests. Add tests for nolibc programs having multiple
.o files.
Powered by blists - more mailing lists