From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: Andy Lutomirski <luto@amacapital.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
linux-api <linux-api@vger.kernel.org>,
Pranith Kumar <bobby.prani@gmail.com>,
Jonathan Rajotte <jonathan.rajotte-julien@efficios.com>
Subject: Re: [PATCH 2/3] selftests: add membarrier syscall test
Date: Tue, 8 Sep 2015 14:02:39 +0000 (UTC) [thread overview]
Message-ID: <739224239.39653.1441720959779.JavaMail.zimbra@efficios.com> (raw)
In-Reply-To: <1441685994.14597.7.camel@ellerman.id.au>
----- On Sep 8, 2015, at 12:19 AM, Michael Ellerman mpe@ellerman.id.au wrote:
> On Mon, 2015-09-07 at 16:01 +0000, Mathieu Desnoyers wrote:
>> ----- On Sep 3, 2015, at 11:36 PM, Michael Ellerman mpe@ellerman.id.au wrote:
>> > On Thu, 2015-09-03 at 15:47 +0000, Mathieu Desnoyers wrote:
>> >>
>> >> My personal experience is that make headers_install does not necessarily play
>> >> well with the distribution header file hierarchy, which requires some tweaks
>> >> to be done by the users (e.g. asm vs x86_64-linux-gnu).
>> >
>> > OK, I've never had issues. What exactly are you doing and how is it going wrong?
>>
>> After some investigation, I noticed the following:
>>
>> 1) I first ran make headers_install as root, which installed the
>> headers within my build tree. I later tried it again as user, and
>> it failed due to permission issues (my bad). This is where I tried
>> to install it into my system rather than under my build directory,
>> which caused a mess.
>
> Yeah OK that's a good point about root.
>
> I tend to build as a regular user and then copy the installed tests to another
> machine where I run them as root.
>
>> 2) Since make kselftest should be run as root (according to make
>> help),
>
> Well some of the tests only work when run as root. IMHO we should support
> running as many tests as possible as non-root, but some of them obviously
> require root.
>
> So you can run them as non-root, but to get maximum coverage you need to run
> them as root.
Works for me. We do something similar in lttng-tools. We use "tap"
(https://testanything.org/) for tests, and explicitly skip all tests that
require root if we detect that we don't run as root. I notice that many
selftests format their own output. The nice part about standardizing on
something like tap is that it simplifies automated parsing of the test
output.
>
>> this means that all the output files generated by the build
>> are owned by root. It leads to permissions issues when trying to
>> rebuild the tests as user afterward. Perhaps we could introduce a
>> distinction between make kselftest_build and make kselftest_run ?
>> The former could be executed as user, and the latter as root.
>
> Right. Personally I don't use the kselftest target at all, I just cd down to
> tools/testing/selftests and run make there.
>
> If it was up to me the kselftest target would go away, because it's only caused
> us trouble so far.
>
> But given it's there we should try to make it work as well as possible. So yeah
> splitting it into build and run would make sense, that way you could do:
>
> $ make headers_install
> $ make kselftest_build
> $ sudo make kselftest_run
>
> And that would hopefully do the right thing.
>
> Would that improve the workflow for you?
Yes. Although I'm wondering why the kernel should be different from many
other projects out there. Why not simply:
- Add a kselftest_build dependency to the kernel build, so tests are always built,
and warnings that arise from modifying anything related to installed headers
will trigger for everyone,
- Add a dependency on headers_install into the obj tree to kselftest_build,
- Optionally add a "make check" alias to "make kselftest".
This way, running the tests becomes as simple as:
make
sudo make check
Documentation is key here: make sure to update Documentation/kselftest.txt to
document where the self-tests are looking for their system headers (not system,
but within usr/ in the obj tree). This is the missing documentation bit that
confused me the most.
>
>> > So that seems to be working for me. Are you doing some different work flow, or
>> > am I just missing something?
>>
>> When doing make headers_install, it indeed installs
>> membarrier.h where we expect it under the build output
>> dir:
>>
>> $ ls usr/include/linux/membarrier.h
>> usr/include/linux/membarrier.h
>>
>> However, if I issue
>>
>> $ make -C tools/testing/selftests TARGETS=membarrier
>> make: Entering directory `/home/efficios/git/linux-next/tools/testing/selftests'
>> for TARGET in membarrier; do \
>> make -C $TARGET; \
>> done;
>> make[1]: Entering directory
>> `/home/efficios/git/linux-next/tools/testing/selftests/membarrier'
>> gcc membarrier_test.c -o membarrier_test
>> membarrier_test.c:2:30: fatal error: linux/membarrier.h: No such file or
>> directory
>> #include <linux/membarrier.h>
>>
>> This is after applying the modifications you requested
>> (see patch attached). Perhaps I did something wrong ?
>
> Yeah sorry, you still need the -I line:
>
> CFLAGS += -I../../../../usr/include/
>
>
> We /should/ add that to lib.mk so it's inherited by everyone, but we haven't
> yet.
Yep, this would be a good start.
>
> So I think if you put that back the instructions I gave you will work?
Yes, it does, thanks!
Mathieu
>
> cheers
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2015-09-08 14:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 20:58 [PATCH 0/3] sys_membarrier (x86, generic) Mathieu Desnoyers
2015-07-10 20:58 ` [PATCH 1/3 v19] sys_membarrier(): system-wide memory barrier (generic, x86) Mathieu Desnoyers
2015-12-04 15:44 ` Michael Kerrisk (man-pages)
2015-12-05 8:48 ` Mathieu Desnoyers
2015-12-11 18:05 ` Michael Kerrisk (man-pages)
2015-12-13 11:44 ` Mathieu Desnoyers
2015-07-10 20:58 ` [PATCH 2/3] selftests: add membarrier syscall test Mathieu Desnoyers
2015-08-31 6:54 ` Michael Ellerman
2015-09-01 17:11 ` Mathieu Desnoyers
2015-09-01 18:32 ` Andy Lutomirski
2015-09-03 9:33 ` Michael Ellerman
2015-09-03 15:47 ` Mathieu Desnoyers
2015-09-04 3:36 ` Michael Ellerman
2015-09-07 16:01 ` Mathieu Desnoyers
2015-09-08 4:19 ` Michael Ellerman
2015-09-08 14:02 ` Mathieu Desnoyers [this message]
2015-09-03 9:24 ` Michael Ellerman
2015-07-10 20:58 ` [PATCH 3/3] selftests: enhance " Mathieu Desnoyers
2015-10-05 23:21 ` [PATCH 0/3] sys_membarrier (x86, generic) Rusty Russell
2015-10-06 2:17 ` Mathieu Desnoyers
2015-10-08 6:22 ` Rusty Russell
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=739224239.39653.1441720959779.JavaMail.zimbra@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=akpm@linux-foundation.org \
--cc=bobby.prani@gmail.com \
--cc=jonathan.rajotte-julien@efficios.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mpe@ellerman.id.au \
/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
Powered by JetHome