linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
Date: Wed, 3 Aug 2022 17:43:12 +0200	[thread overview]
Message-ID: <YuqXkCZEfsSKoIX6@alley> (raw)
In-Reply-To: <CAHk-=wie+VC-R5=Hm=Vrg5PLrJxb1XiV67Efx-9Cr1fBKCWHTQ@mail.gmail.com>

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

  parent reply	other threads:[~2022-08-03 15:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 15:07 [GIT PULL] printk for 5.20 Petr Mladek
2022-08-01 15:45 ` David Laight
2022-08-02  7:37   ` Petr Mladek
2022-08-03  3:19 ` Linus Torvalds
2022-08-03 14:35   ` Sebastian Andrzej Siewior
2022-08-03 14:46     ` David Laight
2022-08-03 15:43   ` Petr Mladek [this message]
2022-08-03 16:06     ` Steven Rostedt
2022-08-03 16:08     ` Linus Torvalds
2022-08-03 16:34       ` Sebastian Andrzej Siewior
2022-08-03 17:08       ` Ingo Molnar
2022-08-09  1:18   ` Thomas Gleixner
2022-08-11 13:38     ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YuqXkCZEfsSKoIX6@alley \
    --to=pmladek@suse.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bigeasy@linutronix.de \
    --cc=jack@suse.cz \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=senozhatsky@chromium.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).