linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	"Shuah Khan" <shuah@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-mm@kvack.org, linux-kselftest@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-s390@vger.kernel.org
Subject: Re: [PATCH 2/8] selftests/vm: use a common gup_test.h
Date: Tue, 29 Sep 2020 10:44:31 -0700	[thread overview]
Message-ID: <aab477bf-4353-5e6b-4cc9-9872c9376ed2@nvidia.com> (raw)
In-Reply-To: <20200929163507.GV9916@ziepe.ca>

On 9/29/20 9:35 AM, Jason Gunthorpe wrote:
> On Mon, Sep 28, 2020 at 01:10:24PM -0700, John Hubbard wrote:
>> On 9/28/20 5:57 AM, Jason Gunthorpe wrote:
>>> On Sun, Sep 27, 2020 at 11:21:53PM -0700, John Hubbard wrote:
>>>> diff --git a/tools/testing/selftests/vm/Makefile b/tools/testing/selftests/vm/Makefile
>>>> index d1ae706d9927..9cc6bc087461 100644
>>>> +++ b/tools/testing/selftests/vm/Makefile
>>>> @@ -130,3 +130,5 @@ endif
>>>>    $(OUTPUT)/userfaultfd: LDLIBS += -lpthread
>>>>    $(OUTPUT)/mlock-random-test: LDLIBS += -lcap
>>>> +
>>>> +$(OUTPUT)/gup_test: ../../../../mm/gup_test.h
>>>
>>> There is no reason to do this, the auto depends will pick up header
>>> files, and gup_test.h isn't a generated file
>>>

Oh, I misread your comment! You were talking about this Makefile
dependency that I'm adding, rather than the ../'s in the path.

Well, for that though, it also has to stay as shown in this patch,
because of this:

I don't see any "gcc -m" type of dependency generation pass happening
in this relatively simple Make system. And so, without including an
explicit header file dependency (at least, that's the simplest way),
changes to gup_test.h are not detected. Both the Makefile code and the
observed behavior back this up. (I expect that this is because there is
less use of header files in this area, because most unit tests are
self-contained within a single .c file.)


>>
>> It is less capable than you might think. Without the admittedly ugly technique
>> above, it fails to build, and as you can see, the include paths that are fed to
>> gcc are just a single one: usr/include:
>>
>> $ make
>> make --no-builtin-rules ARCH=x86 -C ../../../.. headers_install
>> gcc -Wall -I ../../../../usr/include     gup_test.c
>> /kernel_work/linux-next-github/tools/testing/selftests/kselftest_harness.h
>> /kernel_work/linux-next-github/tools/testing/selftests/kselftest.h
>> ../../../../mm/gup_test.h -lrt -o
>> /kernel_work/linux-next-github/tools/testing/selftests/vm/gup_test
>> make[1]: Entering directory '/kernel_work/linux-next-github'
>> gup_test.c:10:10: fatal error: gup_test.h: No such file or directory
>>     10 | #include "gup_test.h"
>>        |          ^~~~~~~~~~~~
> 
> You are supposed to use
> 
>    #include "../../../../mm/gup_test.h"

Good, I'll leave it as I had it.


> I have no idea what weird behavior the makefile is triggering that the
> above include works
> 

See the commit description for yet another Makefile weird behavior point. :)

thanks,
-- 
John Hubbard
NVIDIA


  reply	other threads:[~2020-09-29 17:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-28  6:21 [PATCH 0/8] selftests/vm: gup_test, hmm-tests, assorted improvements John Hubbard
2020-09-28  6:21 ` [PATCH 1/8] mm/gup_benchmark: rename to mm/gup_test John Hubbard
2020-09-28  6:21 ` [PATCH 2/8] selftests/vm: use a common gup_test.h John Hubbard
2020-09-28 12:57   ` Jason Gunthorpe
2020-09-28 20:10     ` John Hubbard
2020-09-29 16:35       ` Jason Gunthorpe
2020-09-29 17:44         ` John Hubbard [this message]
2020-09-29 17:55           ` Jason Gunthorpe
2020-09-29 18:59             ` John Hubbard
2020-09-29 19:08               ` Jason Gunthorpe
2020-09-29 19:48                 ` John Hubbard
2020-09-29 19:53                   ` Jason Gunthorpe
2020-09-29 20:00                     ` Shuah Khan
2020-09-29 20:11                       ` John Hubbard
2020-09-29 20:20                         ` Shuah Khan
2020-09-29 20:36                           ` John Hubbard
2020-09-28  6:21 ` [PATCH 3/8] selftests/vm: rename run_vmtests --> run_vmtests.sh John Hubbard
2020-09-28  6:21 ` [PATCH 4/8] selftests/vm: minor cleanup: Makefile and gup_test.c John Hubbard
2020-09-28  6:21 ` [PATCH 5/8] selftests/vm: only some gup_test items are really benchmarks John Hubbard
2020-09-28  6:21 ` [PATCH 6/8] selftests/vm: gup_test: introduce the dump_pages() sub-test John Hubbard
2020-09-28 19:25   ` Ira Weiny
2020-09-28  6:21 ` [PATCH 7/8] selftests/vm: run_vmtest.sh: update and clean up gup_test invocation John Hubbard
2020-09-28 19:26   ` Ira Weiny
2020-09-28 19:58     ` John Hubbard
2020-09-28  6:21 ` [PATCH 8/8] selftests/vm: hmm-tests: remove the libhugetlbfs dependency John Hubbard
2020-09-28 13:02   ` Jason Gunthorpe
2020-09-28 20:18     ` John Hubbard
2020-09-28 20:45       ` John Hubbard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aab477bf-4353-5e6b-4cc9-9872c9376ed2@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=jgg@ziepe.ca \
    --cc=jglisse@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=rcampbell@nvidia.com \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox