>>>> On Fri, 10 Jul 2020 08:18:49 -0600, Shuah Khan
On 7/10/20 12:02 AM, Yauheni Kaliuta wrote:
> On Thu, Jul 9, 2020 at 6:36 PM Shuah Khan <skhan(a)linuxfoundation.org> wrote:
>> On 7/9/20 12:49 AM, kernel test robot wrote:
>>> FYI, we noticed the following commit (built with gcc-9):
>>> commit: 7cb32086e59b514a832a3e11f5370d37e7cfe022 ("selftests:
>>> simplify run_tests")
>> Thanks for the report. I will drop this patch for now from next.
>> This patch broke x86 32-bit test run
>> make run_tests -C x86
>> Please resubmit the patch with the fix.
> I did not check carefully the report, but isn't it expected that some
> tests are moved after the patch since they originally were placed
The failure doesn't have anything to do with test being moved. You can
reproduce this very easily by running make as shown below in x86 dir
make run_tests -C x86
I reproduced the problem with your and patch and verified that the
problem tracks your patch. I dropped the patch from linux-next
Your other two patches in the series are fine.
In any case, this patch isn't really adding any functionality
is a good cleanup. Let's do the cleanup right or not.
That is because with the patch both lib.mk and x86/Makefile add
the $(OUTPUT) prefix.
So the question is to agree about the convention, should lib.mk
targets expect short test names for TEST_PROGS or full path from
the subtests' Makefiles.
The existing code is hackish (incorrectly -- adding $(OUTPUT)
only to the first list members -- tries to handle it only for
I can make the patch without adding $(OUTPUT). It will require to
fix possible tests which provided only one test and rely on that
behaviour for the OOT build. Do you have an easy way to get a
list of such tests?