[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0c8446a7-473d-49bc-9413-d1b9176f13b1@paulmck-laptop>
Date: Thu, 12 Oct 2023 13:18:18 -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 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?
> > [..]
>
> > > > Ah, and have these been posted to a public mailing list? If not, then I
> > > > need to send them out.
> > >
> > > All patches went through the lists as part of the normal developent
> > > flow. They were not posted after rebasing.
> >
> > I have been sending the group, so I might as well continue the tradition.
>
> Sounds good. If you want me to do something different, please let me
> know.
>
> > There are a couple of substantive checkpatch complaints:
> >
> > 4b4a30ea14d1 ("tools/nolibc: i386: Fix a stack misalign bug on _start")
> > The Fixes SHA-1 should be limited to 12 hex digits.
> > (I am ignoring this, but be prepared for Linus to gripe.
> > If you decide to fix it, I would be happy to repull.)
>
> Done.
Very good, thank you!
> > f2c7923763da ("selftests/nolibc: add tests for multi-object linkage")
> > nolibc-test-linkage.c and nolibc-test-linkage.h need
> > "//" comment for the SPDX comment header. This one needs
> > to be fixed, but this is not in the urgent stack, so there
> > is some time.
>
> nolibc limits itself intentionally to C89 language level which disallows
> C++ style headers.
>
> This should be covered by Documentation/process/license-rules.rst:
>
> If a specific tool cannot handle the standard comment style, then the
> appropriate comment mechanism which the tool accepts shall be used.
I stand corrected, and thank you!
> With that said:
>
> Please pull the changes since the v6.6-rc1 tag from
> https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/
>
> The branch 'fixes' up to and including
> 921992229b1f06df6b649860e4a5f3def1489866 for the v6.6 cycle.
>
> The branch 'next' up to and including
> b8c60e8fc6f755c2cdf7164931afdbfa670c6646 for linux-next.
>
> No full test has been performed as only a commit message was changed.
>
> Testing for full nolibc stack:
> make run: 162 test(s): 162 passed, 0 skipped, 0 failed => status: success
> make run-nolibc-test: 162 test(s): 160 passed, 2 skipped, 0 failed => status: warning
I will pull this in, thank you!
Thanx, Paul
Powered by blists - more mailing lists