Messages in this thread | | | Date | Mon, 16 Oct 2023 15:56:03 -0700 | From | "Paul E. McKenney" <> | 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.
| |