[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <54B93DA1.2010601@osg.samsung.com>
Date: Fri, 16 Jan 2015 09:34:41 -0700
From: Shuah Khan <shuahkh@....samsung.com>
To: Michael Ellerman <mpe@...erman.id.au>, linux-kernel@...r.kernel.org
CC: mmarek@...e.cz, gregkh@...uxfoundation.org,
akpm@...ux-foundation.org, rostedt@...dmis.org, mingo@...hat.com,
davem@...emloft.net, keescook@...omium.org, tranmanphong@...il.com,
cov@...eaurora.org, dh.herrmann@...il.com, hughd@...gle.com,
bobby.prani@...il.com, serge.hallyn@...ntu.com,
ebiederm@...ssion.com, tim.bird@...ymobile.com,
josh@...htriplett.org, koct9i@...il.com,
linux-kbuild@...r.kernel.org, linux-api@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: [PATCH 4/6] kbuild: add a new kselftest_install make target to
install selftests
On 01/09/2015 02:06 AM, Michael Ellerman wrote:
> Add a new make target to install kernel selftests. This new target will
> build and install selftests.
>
> The default is just $(objtree)/selftests. This is preferable to
> something based on $(INSTALL_MOD_PATH) (which defaults to /), as it
> allows a normal user to install the tests. This is similar to the
> default behaviour of make headers_install.
A normal user can install tests at any location they choose by
overriding the default path. For example:
INSTALL_MOD_PATH=/tmp make kselftest_install
will install under tmp.
The approach I used also ties test installs to kernel release.
This addresses an important use-case for kernel developers
that want to compare results from release to release.
The use-case for any user to be able to install tests at
any location is addressed by the above example.
I would like these two above use-cases continued to be supported,
especially the one that tries the test installs to kernel release.
Another goal is to keep changes to the main Makefile minimal and
the rest of the install support belongs under selftests/Makefile
and any other include file (like the one you proposed).
The patch I have in patch v4 addresses the use-cases mentioned above.
I do like the lib.mk approach in general and I am going to review that
patch and give you feedback.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@....samsung.com | (970) 217-8978
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists