lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Wed, 25 Sep 2019 09:52:17 +0100
From:   Cristian Marussi <>
To:     Shuah Khan <>,,,
Subject: Re: Linux 5.4 - bpf test build fails

Hi Shuah, Tim

On 9/24/19 7:23 PM, Shuah Khan wrote:
> On 9/24/19 12:07 PM, wrote:
>>> -----Original Message-----
>>> From: Cristian Marussi on Tuesday, September 24, 2019 7:30 AM
>>> Hi Shuah
>>> On 24/09/2019 17:39, Shuah Khan wrote:
>>>> On 9/24/19 10:03 AM, Shuah Khan wrote:
>>>>> On 9/24/19 9:52 AM, Cristian Marussi wrote:
>>>>>> Hi Shuah
>>>>>> On 24/09/2019 16:26, Shuah Khan wrote:
>>>>>>> Hi Alexei and Daniel,
>>>>>>> bpf test doesn't build on Linux 5.4 mainline. Do you know what's
>>>>>>> happening here.
>>>>>>> make -C tools/testing/selftests/bpf/
>>>>>> side question, since I'm writing arm64/ tests.
>>>>>> my "build-testcases" following the KSFT docs are:
>>>>>> make kselftest
>>>>>> make TARGETS=arm64 kselftest
>>>>>> make -C tools/testing/selftests/
>>>>>> make -C tools/testing/selftests/ INSTALL_PATH=<install-path> install
>>>>>> make TARGETS=arm64 -C tools/testing/selftests/
>>>>>> make TARGETS=arm64 -C tools/testing/selftests/
>>>>>> INSTALL_PATH=<install-path> install
>>>>>> ./ <install-path>
>>>> Cristian,
>>>> That being said, I definitely want to see this list limited to
>>>> a few options.
>>>> One problem is that if somebody wants to do just a build, there
>>>> is no option from the main makefile. I have sent support for that
>>>> a few months ago and the patch didn't got lost it appears. I am
>>>> working on resending those patches. The same is true for install.
>>>> I sent in a patch for that a while back and I am going to resend.
>>>> These will make it easier for users.
>>>> I would really want to get to supporting only these options:
>>>> These are supported now:
>>>> make kselftest
>>>> make TARGETS=arm64 kselftest (one or more targets)
>>>> Replace the following:
>>>> make -C tools/testing/selftests/ with
>>>> make kselftes_build option from main makefile
>>>> Replace this:
>>>> make -C tools/testing/selftests/ INSTALL_PATH=<install-path> install
>>>> with
>>>> make kselftest_install
>>> Yes these top level options would be absolutely useful to avoid multiplication
>>> of build targets to support and test.
>>> Moreover, currently, since there was a lot of test growing into arm64/
>>> inside subdirs like arm64/signal, I support (still under review in fact) in the
>>> arm64/
>>> toplevel makefile the possibility of building/installing by subdirs only, in order
>>> to be able to limit what you want to build/install of a TARGET (resulting in
>>> quicker devel),
>>> issuing something like:
>>> make TARGETS=arm64 SUBTARGETS=signal -C tools/testing/selftests/
>>> if possible, that would be useful if kept functional even in the
>>> new schema. I mean being able to still issue:
>>> make TARGETS=arm64 SUBTARGETS=signal kselftes_build
>>  From a user perspective, instead of adding a new SUBTARGETS variable,
>> I would prefer something like the following:
>> make TARGET=arm64/signal kselftest_build
>> If you just add a single flat subsidiary namespace, then it doesn't support further
>> increasing the directory depth in the future.
> TARGETS is make variable. Adding sub-targets might not be easy without
> cluttering the selftests main Makefile. I will have to look into it.

I was NOT proposing in fact to introduce handling of SUBTARGETS at the toplevel kselftest
Makefile, just not to kill the possibility for interested subsystems to handle it as they
wish in their own toplevel subsystem Makefile like in arm64/Makefile in:

(probably better renaming SUBTARGETS->ARM64_SUBTARGETS in the next v7 to avoid name clashing)

Because it's painful from the development perspective not having the possibility to selectively
build/install only a subset/subdir of the chosen TARGETS; but it's a very subsystem specific issue
and not everybody need it, so I'd let the respective TARGETS subsystems handle it if they want/need.



> thanks,
> -- Shuah

Powered by blists - more mailing lists