From: Mathieu Desnoyers <mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
To: Michael Ellerman <mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
Cc: Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
Andrew Morton
<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Pranith Kumar
<bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Jonathan Rajotte
<jonathan.rajotte-julien-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
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-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
----- On Sep 8, 2015, at 12:19 AM, Michael Ellerman mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org wrote:
> On Mon, 2015-09-07 at 16:01 +0000, Mathieu Desnoyers wrote:
>> ----- On Sep 3, 2015, at 11:36 PM, Michael Ellerman mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org 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
WARNING: multiple messages have this Message-ID (diff)
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: 35+ 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)
[not found] ` <5661B4E8.2070801-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-12-05 8:48 ` Mathieu Desnoyers
2015-12-05 8:48 ` Mathieu Desnoyers
[not found] ` <1635187109.213051.1449305303824.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2015-12-11 18:05 ` Michael Kerrisk (man-pages)
2015-12-11 18:05 ` Michael Kerrisk (man-pages)
[not found] ` <566B107D.802-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-12-13 11:44 ` Mathieu Desnoyers
2015-12-13 11:44 ` Mathieu Desnoyers
2015-07-10 20:58 ` [PATCH 2/3] selftests: add membarrier syscall test Mathieu Desnoyers
[not found] ` <1436561912-24365-3-git-send-email-mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2015-08-31 6:54 ` Michael Ellerman
2015-08-31 6:54 ` Michael Ellerman
[not found] ` <1441004040.5735.7.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
2015-09-01 17:11 ` Mathieu Desnoyers
2015-09-01 17:11 ` Mathieu Desnoyers
[not found] ` <1071313434.33305.1441127478843.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2015-09-01 18:32 ` Andy Lutomirski
2015-09-01 18:32 ` Andy Lutomirski
2015-09-03 9:33 ` Michael Ellerman
[not found] ` <1441272839.26379.2.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
2015-09-03 15:47 ` Mathieu Desnoyers
2015-09-03 15:47 ` Mathieu Desnoyers
[not found] ` <1734164155.35899.1441295233847.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2015-09-04 3:36 ` Michael Ellerman
2015-09-04 3:36 ` Michael Ellerman
2015-09-07 16:01 ` Mathieu Desnoyers
[not found] ` <2098747118.39146.1441641706942.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2015-09-08 4:19 ` Michael Ellerman
2015-09-08 4:19 ` Michael Ellerman
[not found] ` <1441685994.14597.7.camel-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.org>
2015-09-08 14:02 ` Mathieu Desnoyers [this message]
2015-09-08 14:02 ` Mathieu Desnoyers
2015-09-03 9:24 ` Michael Ellerman
2015-09-03 9:24 ` Michael Ellerman
2015-07-10 20:58 ` [PATCH 3/3] selftests: enhance " Mathieu Desnoyers
[not found] ` <1436561912-24365-1-git-send-email-mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2015-10-05 23:21 ` [PATCH 0/3] sys_membarrier (x86, generic) Rusty Russell
2015-10-05 23:21 ` Rusty Russell
[not found] ` <87vbaknbp8.fsf-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2015-10-06 2:17 ` Mathieu Desnoyers
2015-10-06 2:17 ` Mathieu Desnoyers
[not found] ` <1840779213.18838.1444097856879.JavaMail.zimbra-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org>
2015-10-08 6:22 ` Rusty Russell
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-vg+e7yoek/dwk0htik3j/w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=bobby.prani-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=jonathan.rajotte-julien-vg+e7yoeK/dWk0Htik3J/w@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org \
--cc=mpe-Gsx/Oe8HsFggBc27wqDAHg@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.