[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fab2e2e1-311f-6e61-2ba7-0119b8281524@linuxfoundation.org>
Date: Mon, 11 Jul 2022 17:08:04 -0600
From: Shuah Khan <skhan@...uxfoundation.org>
To: Anders Roxell <anders.roxell@...aro.org>
Cc: Guillaume Tucker <guillaume.tucker@...labora.com>,
Masahiro Yamada <masahiroy@...nel.org>,
Michal Marek <michal.lkml@...kovi.net>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Shuah Khan <shuah@...nel.org>,
Kees Cook <keescook@...omium.org>,
Naresh Kamboju <naresh.kamboju@...aro.org>,
kernel@...labora.com, linux-kbuild@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH 0/4] Fix kselftest build with sub-directory
On 7/11/22 6:13 AM, Anders Roxell wrote:
> On Fri, 8 Jul 2022 at 19:14, Shuah Khan <skhan@...uxfoundation.org> wrote:
>>
>> On 7/8/22 10:23 AM, Guillaume Tucker wrote:
>>> Earlier attempts to get "make O=build kselftest-all" to work were
>>> not successful as they made undesirable changes to some functions
>>> in the top-level Makefile. This series takes a different
>>> approach by removing the root cause of the problem within
>>> kselftest, which is when the sub-Makefile tries to install kernel
>>> headers "backwards" by calling make with the top-level Makefile.
>>> The actual issue comes from the fact that $(srctree) is ".." when
>>> building in a sub-directory with "O=build" which then obviously
>>> makes "-C $(top_srcdir)" point outside of the real source tree.
>>>
>>> With this series, the generic kselftest targets work as expected
>>> from the top level with or without a build directory e.g.:
>>>
>>> $ make kselftest-all
>>>
>>> $ make O=build kselftest-all
>>>
>>> Then in order to build using the sub-Makefile explicitly, the
>>> headers have to be installed first. This is arguably a valid
>>> requirement to have when building a tool from a sub-Makefile.
>>> For example, "make -C tools/testing/nvdimm/" fails in a similar
>>> way until <asm/rwonce.h> has been generated by a kernel build.
>>>
>>> Guillaume Tucker (4):
>>> selftests: drop khdr make target
>>> selftests: stop using KSFT_KHDR_INSTALL
>>> selftests: drop KSFT_KHDR_INSTALL make target
>>> Makefile: add headers_install to kselftest targets
>>>
>>
>> This takes us to back to the state before b2d35fa5fc80 added
>> khdr support. I reluctantly agreed to the change and it has
>> proven to be a problematic change. I would rather have had the
>> dependency stated that headers should be installed prior to
>> building tests - test build depends on kernel build anyway and
>> having dependency on headers having build isn't a huge deal.
>
> I agree that it's not a huge deal.
>
>>
>> So I am in favor of getting rid of khdr support. However, this
>> khdr support was a change originated from Linaro test ring. Undoing
>> this might have implication on their workflow.
>
> It shouldn't be a problem.
> I've been running these patches through a smoke test and it looks
> good.
>
> Tested-by: Anders Roxell <anders.roxell@...aro.org>
>
>
Thank you Anders for confirming this isn't a problem for Linaro workflow
and testing.
Than you Guillaume for fixing the problem. I will apply these for 5.20-rc1.
thanks,
-- Shuah
Powered by blists - more mailing lists