Re: [PATCH] selftests/nolibc: add tests for multi-object linkage

[Paul E. McKenney]

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.