linux-kernel - Re: [PATCH 0/3] selfttests: timers ksft

lists.openwall.net		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 linux-cve-announce 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:   Thu, 10 Aug 2017 17:57:42 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Shuah Khan <shuah@...nel.org>
Cc:     Shuah Khan <shuahkh@....samsung.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Stephen Boyd <sboyd@...eaurora.org>,
        lkml <linux-kernel@...r.kernel.org>,
        linux-kselftest@...r.kernel.org
Subject: Re: [PATCH 0/3] selfttests: timers ksft_ stubs handling changes

On Thu, Aug 10, 2017 at 5:51 PM, Shuah Khan <shuah@...nel.org> wrote:
> On 08/10/2017 06:10 PM, John Stultz wrote:
>> On Thu, Aug 10, 2017 at 4:53 PM, Shuah Khan <shuahkh@....samsung.com> wrote:
>>> This patch series consists of changes to:
>>>
>>> Move ksft_ stubs from individual tests into kselftest_stubs.h and change
>>> tests to include it.
>>>
>>> Fix posix_timers and freq-step tests to run without ksft_ framework.
>>>
>>> This is in preparation to convert timers tests to ksft TAP 13 format.
>>>
>>> Question for John Stultz:
>>>
>>> The conversion work will be easier without the requirement to be able to
>>> build and run these tests without ksft_ framework. So far the stubs are
>>> simpler. It is might be necessary to ifdef some code paths to have sane
>>> output for both KTEST and !KTEST cases.
>>>
>>> Would it be easier to pull in kselftest.h into timers external repo
>>> (if one still exists). This is based on the observation that newer
>>> timer tests don't support !KTEST case e.g: posix_timers and freq-step.
>>>
>>> Please review and let me know how you would like me to proceed with the
>>> conversion. I am looking for answer to how important is it to continue to
>>> support !KTEST case.
>>
>> Yea. I'm thinking at this point I'm fine with dropping the attempt to
>> keep kselftest and my external timekeeping tests in sync.
>
> Would you like me to clean !KTEST support or leave it the way it is.
> It sounds like, I will drop these patches anyway.

Yea. I think its ok to drop !KTEST.

thanks
-john