On Sun, Jun 04, 2023 at 03:57:54PM -0700, Paul E. McKenney wrote: > On Sun, Jun 04, 2023 at 03:20:11PM +0200, Willy Tarreau wrote: > > Hello Paul, > > > > Thomas and Zhangjin have provided significant nolibc cleanups, and > > fixes, as well as preparation work to later support riscv32. > > > > These consist in the following main series: > > - generalization of stackprotector to other archs that were not > > previously supported (riscv, mips, loongarch, arm, arm64) > > > > - general cleanups of the makefile, test report output, deduplication > > of certain tests > > > > - slightly better compliance of some tests performed on certain syscalls > > (e.g. no longer pass (void*)1 to gettimeofday() since glibc hates it). > > > > - add support for nanoseconds in stat() and statx() > > > > - fixes for some syscalls (e.g. ppoll() has 5 arguments not 4) > > > > - fixes around limits.h and INT_MAX / INT_FAST64_MAX > > > > I rebased the whole series on top of your latest dev branch (d19a9ca3d5) > > and it works fine for all archs. > > > > I don't know if you're still planning on merging new stuff in this area > > for 6.5 or not (since I know that it involves new series of tests on your > > side as well), but given that Zhangjin will engage into deeper changes > > later for riscv32 that will likely imply to update more syscalls to use > > the time64 ones, I would prefer to split the cleanups from the hard stuff, > > but I'll let you judge based on the current state of what's pending for > > 6.5. > > > > In any case I'm putting all this here for now (not for merge yet): > > > > git://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git 20230604-nolibc-rv32+stkp6 > > > > I'd like Thomas and Zhangjin to perform a last check to confirm they're > > OK with this final integration. > > Given that the testing converges by the end of this week, I can't see > any reason why these cannot make v6.5. Perfect, thank you! > (There were some kernel test > robot complaints as well, valid or not I am not sure.) You mean in relation with nolibc stuff (or nolibc-test) or something totally different ? Best regards, Willy
