From: Joe Perches <joe@perches.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Petr Mladek <pmladek@suse.com>,
John Ogness <john.ogness@linutronix.de>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
kexec@lists.infradead.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
Date: Fri, 14 Aug 2020 20:08:02 -0700 [thread overview]
Message-ID: <ccc21619fdee79985f619adeb49bd5713dc97d80.camel@perches.com> (raw)
In-Reply-To: <CAHk-=wjNZ40akqgnb1y=dSYv1fX2Wk1SGF5hAzuV2azi5oQ+Tg@mail.gmail.com>
On Fri, 2020-08-14 at 19:33 -0700, Linus Torvalds wrote:
> On Fri, Aug 14, 2020 at 4:52 PM Joe Perches <joe@perches.com> wrote:
> > On Fri, 2020-08-14 at 15:46 -0700, Linus Torvalds wrote:
> > > This is why I think any discussion that says "people should buffer
> > > their lines themselves and we should get rid if pr_cont()" is
> > > fundamentally broken.
> > >
> > > Don't go down that hole. I won't take it. It's wrong.
> >
> > I don't think it's wrong per se.
>
> It's *absolutely* and 100% wrong.
>
> Yes, any random *user* of pr_cont() can decide to buffer on it's own.
Which I believe is the point of the discussion,
not the complete removal of KERN_CONT.
> But when the discussion is about printk() - the implementation, not
> the users - then it's complete and utter BS to talk about trying to
> get rid of pr_cont().
>
> See the difference?
Sure, but I fail to see where anyone said get rid of pr_cont
in this thread. It seems all that was discussed was just
various schemes to improve coalescing output.
WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Petr Mladek <pmladek@suse.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
John Ogness <john.ogness@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
kexec@lists.infradead.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: POC: Alternative solution: Re: [PATCH 0/4] printk: reimplement LOG_CONT handling
Date: Fri, 14 Aug 2020 20:08:02 -0700 [thread overview]
Message-ID: <ccc21619fdee79985f619adeb49bd5713dc97d80.camel@perches.com> (raw)
In-Reply-To: <CAHk-=wjNZ40akqgnb1y=dSYv1fX2Wk1SGF5hAzuV2azi5oQ+Tg@mail.gmail.com>
On Fri, 2020-08-14 at 19:33 -0700, Linus Torvalds wrote:
> On Fri, Aug 14, 2020 at 4:52 PM Joe Perches <joe@perches.com> wrote:
> > On Fri, 2020-08-14 at 15:46 -0700, Linus Torvalds wrote:
> > > This is why I think any discussion that says "people should buffer
> > > their lines themselves and we should get rid if pr_cont()" is
> > > fundamentally broken.
> > >
> > > Don't go down that hole. I won't take it. It's wrong.
> >
> > I don't think it's wrong per se.
>
> It's *absolutely* and 100% wrong.
>
> Yes, any random *user* of pr_cont() can decide to buffer on it's own.
Which I believe is the point of the discussion,
not the complete removal of KERN_CONT.
> But when the discussion is about printk() - the implementation, not
> the users - then it's complete and utter BS to talk about trying to
> get rid of pr_cont().
>
> See the difference?
Sure, but I fail to see where anyone said get rid of pr_cont
in this thread. It seems all that was discussed was just
various schemes to improve coalescing output.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2020-08-15 21:55 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 23:48 [PATCH 0/4] printk: reimplement LOG_CONT handling John Ogness
2020-07-17 23:48 ` John Ogness
2020-07-17 23:48 ` [PATCH 1/4] printk: ringbuffer: support dataless records John Ogness
2020-07-17 23:48 ` John Ogness
2020-07-20 14:49 ` John Ogness
2020-07-20 14:49 ` John Ogness
2020-07-17 23:48 ` [PATCH 2/4] printk: store instead of processing cont parts John Ogness
2020-07-17 23:48 ` John Ogness
2020-07-19 14:35 ` Sergey Senozhatsky
2020-07-19 14:35 ` Sergey Senozhatsky
2020-07-19 18:27 ` Linus Torvalds
2020-07-19 18:27 ` Linus Torvalds
2020-07-20 1:50 ` Sergey Senozhatsky
2020-07-20 1:50 ` Sergey Senozhatsky
2020-07-20 18:30 ` Linus Torvalds
2020-07-20 18:30 ` Linus Torvalds
2020-07-21 3:53 ` Joe Perches
2020-07-21 3:53 ` Joe Perches
2020-07-21 14:42 ` Sergey Senozhatsky
2020-07-21 14:42 ` Sergey Senozhatsky
2020-07-21 14:57 ` John Ogness
2020-07-21 14:57 ` John Ogness
2020-07-29 2:03 ` Sergey Senozhatsky
2020-07-29 2:03 ` Sergey Senozhatsky
2020-07-21 15:40 ` Linus Torvalds
2020-07-21 15:40 ` Linus Torvalds
2020-07-28 2:22 ` Sergey Senozhatsky
2020-07-28 2:22 ` Sergey Senozhatsky
2020-07-17 23:48 ` [PATCH 3/4] printk: process cont records during reading John Ogness
2020-07-17 23:48 ` John Ogness
2020-07-17 23:48 ` [PATCH 4/4] ipconfig: cleanup printk usage John Ogness
2020-07-17 23:48 ` John Ogness
2020-07-18 0:00 ` [PATCH 0/4] printk: reimplement LOG_CONT handling Linus Torvalds
2020-07-18 0:00 ` Linus Torvalds
2020-07-18 14:42 ` John Ogness
2020-07-18 14:42 ` John Ogness
2020-07-18 17:42 ` Linus Torvalds
2020-07-18 17:42 ` Linus Torvalds
2020-08-11 16:05 ` Petr Mladek
2020-08-11 16:05 ` Petr Mladek
2020-08-12 16:39 ` POC: Alternative solution: " Petr Mladek
2020-08-12 16:39 ` Petr Mladek
2020-08-13 0:24 ` John Ogness
2020-08-13 0:24 ` John Ogness
2020-08-13 5:18 ` Sergey Senozhatsky
2020-08-13 5:18 ` Sergey Senozhatsky
2020-08-13 7:44 ` John Ogness
2020-08-13 7:44 ` John Ogness
2020-08-13 8:41 ` Petr Mladek
2020-08-13 8:41 ` Petr Mladek
2020-08-13 10:29 ` John Ogness
2020-08-13 10:29 ` John Ogness
2020-08-13 11:30 ` Petr Mladek
2020-08-13 11:30 ` Petr Mladek
2020-08-14 3:34 ` Sergey Senozhatsky
2020-08-14 3:34 ` Sergey Senozhatsky
2020-08-14 8:16 ` John Ogness
2020-08-14 8:16 ` John Ogness
2020-08-14 9:12 ` Petr Mladek
2020-08-14 9:12 ` Petr Mladek
2020-08-13 11:54 ` Sergey Senozhatsky
2020-08-13 11:54 ` Sergey Senozhatsky
2020-08-14 9:04 ` Petr Mladek
2020-08-14 9:04 ` Petr Mladek
2020-08-14 22:46 ` Linus Torvalds
2020-08-14 22:46 ` Linus Torvalds
2020-08-14 23:52 ` Joe Perches
2020-08-14 23:52 ` Joe Perches
2020-08-15 2:33 ` Linus Torvalds
2020-08-15 2:33 ` Linus Torvalds
2020-08-15 3:08 ` Joe Perches [this message]
2020-08-15 3:08 ` Joe Perches
2020-08-15 9:25 ` David Laight
2020-08-15 9:25 ` David Laight
2020-08-15 5:41 ` Sergey Senozhatsky
2020-08-15 5:41 ` Sergey Senozhatsky
2020-08-13 7:51 ` Petr Mladek
2020-08-13 7:51 ` Petr Mladek
2020-08-13 7:31 ` Petr Mladek
2020-08-13 7:31 ` Petr Mladek
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=ccc21619fdee79985f619adeb49bd5713dc97d80.camel@perches.com \
--to=joe@perches.com \
--cc=gregkh@linuxfoundation.org \
--cc=john.ogness@linutronix.de \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=sergey.senozhatsky@gmail.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.