Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v2] twist: allow converting pr_devel()/pr_debug() into
 snprintf()
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Petr Mladek <pmladek@suse.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Dmitry Vyukov <dvyukov@google.com>,
        Ondrej Mosnacek <omosnace@redhat.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>
References: <e3b30905-4497-29b4-4636-a313283dbc56@i-love.sakura.ne.jp>
 <20200528065603.3596-1-penguin-kernel@I-love.SAKURA.ne.jp>
 <20200528110646.GC11286@linux-b0ei>
 <e0d6c04f-7601-51e7-c969-300e938dedc0@i-love.sakura.ne.jp>
 <CAHk-=wgz=7MGxxX-tmMmdCsKyYJkuyxNc-4uLP=e_eEV=OzUaw@mail.gmail.com>
 <CAHk-=wjW+_pjJzVRMuCbLhbWLkvEQVYJoXVBYGNW2PUgtX1fDw@mail.gmail.com>
 <13b0a475-e70e-c490-d34d-0c7a34facf7c@i-love.sakura.ne.jp>
 <CAHk-=wjj9ooYACNvO2P_Gr_=aN0g=iEqtg0TwBJo18wbn4gthg@mail.gmail.com>
 <6116ed2e-cee1-d82f-6b68-ddb1bbb6abe2@i-love.sakura.ne.jp>
 <CAHk-=wiVQUo_RJAaivHU5MFdznNOX4GKgJH1xrFc83e9oLnuvQ@mail.gmail.com>
From:   Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Message-ID: <19d377d3-8037-8090-0f99-447f72cc1d8c@i-love.sakura.ne.jp>
Date:   Fri, 29 May 2020 13:47:53 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <CAHk-=wiVQUo_RJAaivHU5MFdznNOX4GKgJH1xrFc83e9oLnuvQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2020/05/29 11:24, Linus Torvalds wrote:
> Some flags do end up having to be practically system-wide, because
> they end up being used in contexts other than the test environment (ie
> anything that ends up doing workqueues or networking or VM or whatever
> - it's a "global context").

Right. And since fuzz testing can't determine whether it will involve
"global context", the options for fuzz testing (currently referenced as
"twist") can't be "per process". It might be possible to make the twist
options "per boot", but we are conflicting on whether making the twist
options "per boot" worth the effort.

> At the same time, some of the flags might well be "in the test
> environment" if they act on behavior that is all synchronous. Then
> other testers can use them on production machines for testing, even
> when the kernel might be used for other things at the same time.

I don't think that people use their machines for testing and non-testing
at the same time. When testing kernels, people enable a lot of debugging
kernel config options (e.g. KASAN, lockdep) because finding bugs has
higher priority than faster kernels. Some of debugging functionality
could be enabled/disabled using kernel command line, but it is hardly
possible to convert such debugging functionality into "per process".
It is much safer to run a qemu-kvm instance on their machines if they
want to test kernels without affecting the rest of their machines.

> And absolutely none of this should be named "twist". If you can't make
> a config have a sane name that talks about what it does, then it
> shouldn't exist at all.

CONFIG_TWIST_* options are analogy of CONFIG_DEBUG_* options.
The TWIST part is a prefix for grouping. If you don't like the grouping,
it is just a matter of renaming CONFIG_TWIST_* options.

> And making that a build-time option is the worst of all worlds.

Can we avoid discussing "the config option naming" (which is build-time
things) and "the kernel command line option" (which is boot-time things)
at the same time? What I am saying is

 THE TWIST OPTIONS ARE INTENDED FOR "IMPROVING THE QUALITY OF KERNEL TESTING"

which will in turn help improving the quality of kernel itself, and your
insistence on making them boot-time things (which might increase flexibility
for users) can decrease the reliability/robustness of testing.