linux-kernel - Re: [PATCH v3] replace timeconst bc script with an sh script

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]

Message-ID: <EC20169B-26FF-4AC0-AABE-B6FFB0B3AA40@zytor.com>
Date:   Sun, 03 Nov 2019 19:03:36 -0800
From:   hpa@...or.com
To:     Ethan Sommer <e5ten.arch@...il.com>
CC:     Jonathan Corbet <corbet@....net>,
        Federico Vaga <federico.vaga@...a.pv.it>,
        "Chang S. Bae" <chang.seok.bae@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Kieran Bingham <kieran.bingham@...asonboard.com>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        Mark Rutland <mark.rutland@....com>,
        John Stultz <john.stultz@...aro.org>,
        Kees Cook <keescook@...omium.org>,
        Corey Minyard <cminyard@...sta.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-doc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3] replace timeconst bc script with an sh script

On November 3, 2019 3:57:06 PM PST, Ethan Sommer <e5ten.arch@...il.com> wrote:
>> The point isn't to make it work *now*, but getting it to *stay* work.
>Since the only thing that can change to affect the outcome of the
>script
>or program is the value of CONFIG_HZ, isn't knowing that it works
>within
>a range of any reasonable values to set CONFIG_HZ to enough to know
>that
>it will stay working? I just tested again using the bc script and my C
>program, and this time I tested every possible value up to 100000, and
>they both still matched output. It doesn't seem like there's something
>that would cause the C program to stop working in the future due to
>precision issues.

No, it's not. Because some time we are going to want to change the way the constants we need, or use them for something else, and be so on.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.