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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALAqxLWJfBZ3oEowHiAvcfy1fNqOnm80mrUv3HnyTxPbmL8Z7Q@mail.gmail.com>
Date:   Thu, 10 Aug 2017 17:10:55 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Shuah Khan <shuahkh@....samsung.com>
Cc:     Shuah Khan <shuah@...nel.org>,
        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 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.

Though something that might be nice however is having some place that
keeps tarball releases of kselftest around? As it would make pulling
tests onto a target machine a bit easier. Does that already exist?

thanks
-john