lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 23 May 2022 22:23:36 +0200
From:   Willy Tarreau <w@....eu>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     "Paul E. McKenney" <paulmck@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Kernel Team <kernel-team@...com>
Subject: Re: [GIT PULL] nolibc changes for v5.19

On Mon, May 23, 2022 at 09:56:05PM +0200, Willy Tarreau wrote:
> On Mon, May 23, 2022 at 11:42:48AM -0700, Linus Torvalds wrote:
> > On Fri, May 20, 2022 at 11:24 AM Paul E. McKenney <paulmck@...nel.org> wrote:
> > >
> > > This pull request adds a number of library functions and splits this
> > > library into multiple files.
> > 
> > Well, this is annoying.
> > 
> > You add the rule to test and install this, and "make help" will list
> > "nolibc" as a target, but that is not actually true at all.
> > 
> > So what's the appropriate way to actually test this pull somehow?
> > 
> > I'm guessing it's along the lines of
> > 
> >     make ARCH=x86 nolibc_headers
> > 
> > in the tools directory, but then I got bored and decided I need to
> > just continue the merge window.
> > 
> > I've pulled this, but it all makes me go "Hmm, I'd have liked to maybe
> > even build test it".
> 
> I did. I must confess I'm embarrassed now because when I added the
> entries there, exactly in order to reuse what was in place, I found
> it a bit tricky to launch the tests, but after that I felt OK with
> it. Now it's been a quite some time now and I don't remember the exact
> way to trigger the tests there, so it's likely that I didn't leave
> enough info in the commit messages :-( Let me have a look and figure
> again how to start the tests.

So I've figured it again. When you run:

   make tools/help

you get the help of tools/ commands, and:

   make tools/command_<target>

actually runs the <target> target of tools/command.

Here we have:

   make tools/nolibc_headers

which installs only the nolibc headers for the selected architecture
into tools/include/nolibc/sysroot, and:

   make tools/nolibc_headers_standalone

which does the same in addition with a make headers;make headers_install
into that directory so that we get a completely usable sysroot.

Finally:
 
   make tools/nolibc_clean

will clean that directory.

I hadn't found any foo_help target for other commands so I assumed it
was not what users would look like. But if you find it useful I can
easily add:

   make tools/nolibc_help

to enumerate these commands.

Hoping that clarifies the situation.

Regards,
Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ