From: Will Deacon <will.deacon@arm.com>
To: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jan Kara <jack@suse.cz>,
"mm-commits@vger.kernel.org" <mm-commits@vger.kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"kay@vrfy.org" <kay@vrfy.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: + printk-print-initial-logbuf-contents-before-re-enabling-interrupts.patch added to -mm tree
Date: Thu, 8 May 2014 15:34:07 +0100 [thread overview]
Message-ID: <20140508143407.GB8981@arm.com> (raw)
In-Reply-To: <20140507174151.3c28f15a@alan.etchedpixels.co.uk>
Hi Alan,
On Wed, May 07, 2014 at 05:41:51PM +0100, One Thousand Gnomes wrote:
> > Possibly, but I fear we'd incur the wrath of Alan after reading that other
> > thread. Having a CONFIG_ option or similar to control the amount of printing
> > we do is very similar to the command-line option Jan proposed in his series.
>
> I've nothing against a configuration option, and having a printk that
> queued most stuff to the serial IRQ handler on overflow and a boot option
> of printk=synchronous for debug work would be awesome in my book. Many end
> production boxes don't give a toss about losing the odd bit of data they
> just need to shift the logs somewhere for filing.
Ok, I'll revisit this with a command-line option for the debug case. Thanks.
> All these "clever" approaches just seem to me to be ever more convoluted
> attempts to fail to deal with the simple reality that if you put more
> down the sewage pipe than fits it has to overflow somewhere.
>
> Our tty drivers have a fifo, our tty drivers have an IRQ driven write
> operation. It seems silly to be adding magic to solve the problem rather
> than just using it (and in turn getting a ton of other consoles for free,
> and being able to take GregKH's current usb console hack out)
Hmm, I'm not at all familiar with the tty layer, so I'd have to go and take
a look. Jan, did you look at this at all?
Will
next prev parent reply other threads:[~2014-05-08 14:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53640c8c.5++0zeO0pmfqKMwm%akpm@linux-foundation.org>
2014-05-02 22:46 ` + printk-print-initial-logbuf-contents-before-re-enabling-interrupts.patch added to -mm tree Jan Kara
2014-05-06 12:06 ` Will Deacon
2014-05-06 12:29 ` Jan Kara
2014-05-06 13:12 ` Will Deacon
2014-05-06 13:50 ` Peter Zijlstra
2014-05-06 14:00 ` Jan Kara
2014-05-06 15:00 ` Will Deacon
2014-05-06 20:00 ` Jan Kara
2014-05-07 9:46 ` Will Deacon
2014-05-06 22:05 ` Andrew Morton
2014-05-07 9:58 ` Will Deacon
2014-05-07 16:41 ` One Thousand Gnomes
2014-05-08 14:34 ` Will Deacon [this message]
2014-05-12 17:15 ` Jan Kara
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=20140508143407.GB8981@arm.com \
--to=will.deacon@arm.com \
--cc=akpm@linux-foundation.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=jack@suse.cz \
--cc=kay@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=peterz@infradead.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