Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 3 Aug 2022 17:43:12 +0200
From:   Petr Mladek <pmladek@suse.com>
To:     Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Sergey Senozhatsky <senozhatsky@chromium.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        John Ogness <john.ogness@linutronix.de>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
        Thomas Gleixner <tglx@linutronix.de>, Jan Kara <jack@suse.cz>,
        Peter Zijlstra <peterz@infradead.org>,
        linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL] printk for 5.20
Message-ID: <YuqXkCZEfsSKoIX6@alley>
References: <YufsTLpighCI7qSf@alley>
 <CAHk-=wie+VC-R5=Hm=Vrg5PLrJxb1XiV67Efx-9Cr1fBKCWHTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHk-=wie+VC-R5=Hm=Vrg5PLrJxb1XiV67Efx-9Cr1fBKCWHTQ@mail.gmail.com>
Precedence: bulk

On Tue 2022-08-02 20:19:34, Linus Torvalds wrote:
> On Mon, Aug 1, 2022 at 8:08 AM Petr Mladek <pmladek@suse.com> wrote:
> >
> > - Completely disable printing on consoles with CONFIG_RT.
> 
> I don't think this is acceptable.
> 
> We don't suddenly change behavior just because some random developer
> has decided "this is the RightThing(tm) to do".
> 
> Users matter.

I fully agree.


> For all we know, there may be random users who are playing around with
> PREEMPT_RT. They don't *have* to, but they want to.
>
> Just saying "you get no console because you wanted to try it out" is
> simply not acceptable.

This is where I probably made a mistake. I know that PREEMPT_RT is not
production ready in upstream. And I am not sure what people playing
with it expect.

My first reaction was that the patch was a joke. I tried to
formulate the concerns somehow, see
https://lore.kernel.org/all/Yt6MzEEFfpyTBIIj@alley/

Hmm, I ignored my intuition and let people familiar with PREEMPT_RT
decide. I knew that John was working on the proper solution so
it was not supposed to be final one.


> Seriously, even if you have strict RT requirements, you may also have
> strict debugging requirements, and if something goes wrong, you want
> to KNOW ABOUT IT. At that point, your RT rules may well fly out the
> window, because you have more serious problems.
>
> End result: no way will I accept this kind of completely arbitrary and
> frankly not very intelligent patch.
> 
> If people want to disable console printing, that's THEIR CHOICE. It
> could be a new config variable where you ASK people about what they
> want. Not this kind of idiotic tying together of things.
> 
> And guys, I want to make it really clear how disappointed I am with
> the printk tree lately. There seems to be some kind of hardline
> religious fervor having taken over to make these kinds of "this is how
> it has to be done, screw any sanity or common sense".
>
> There is exactly one thing you should hold sacred: don't break
> people's setups. All the rest is just engineering, and a HUGE part of
> "engineering" is to realize that everything is a trade-off.
>
> Linux kernel development is a pragmatic thing where existing users and
> existing code matters, and you don't get to just throw it all away
> because you have some odd personal hangup.
>
> And printing messages to a console is not some "oh, we'll just stop
> doing that because you asked for PREEMPT_RT".

My thinking was that PREEMPT_RT was used only by some rather small
community that was very well aware of the upstream status. I kind of
though that this was their choice.

I think that I underestimated political and human influences.


> Put another way: not only am I not pulling this, I'm concerned that I
> will not be pulling printk patches in the future either because of
> where these pull requests seem to be trending.

I admit that _I did a big mistake_ by this "disable consoles on RT"
patch. It broke many principles and it was a real hack.

On the positive side. My intuition told me that it was very controversial.
This is why I clearly described the effect. And it was the very first
sentence in the commit message. I think that I made it _very visible_.

The previous merge window was different. We tried to get into mainline
a feature that many people wanted for years (since 2012). We though
that it was ready but it wasn't and we took it back in time.


Otherwise, I think that I am quite demanding maintainer. I focus on
that the change must make sense, must not break existing behavior,
any user interface must be sane, the code must be readable and
maintainable.

I do mistakes. But I have learned big lessons last and this merge
window. I am going to believe more into my intuition and be more
strict.

I am going to take a break and think twice before sending any
further pull request.

Best Regards,
Petr