Thread (21 messages) flat view 21 messages, 5 authors, 2015-12-13

Re: [PATCH 2/3] selftests: add membarrier syscall test

From: Michael Ellerman <hidden>
Date: 2015-09-08 04:20:00
Also in: lkml

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:
quoted
On Thu, 2015-09-03 at 15:47 +0000, Mathieu Desnoyers wrote:
quoted
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.
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?
quoted
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.

So I think if you put that back the instructions I gave you will work?

cheers
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help