All of lore.kernel.org
 help / color / mirror / Atom feed
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Jan Kara <jack@suse.cz>, LKML <linux-kernel@vger.kernel.org>,
	pmladek@suse.cz, Frederic Weisbecker <fweisbec@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 8/8] printk: Add config option for disabling printk offloading
Date: Tue, 22 Apr 2014 11:22:59 +0100	[thread overview]
Message-ID: <20140422112259.5f106a44@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <20140418115438.1e65e07af17e3ba6d7c554db@linux-foundation.org>

On Fri, 18 Apr 2014 11:54:38 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> On Wed, 26 Mar 2014 20:28:15 +0100 Jan Kara <jack@suse.cz> wrote:
> 
> > > All the afflicted consoles are serial, all go via the uart layer as far
> > > as I can see.
> > > 
> > > The uart layer has a queue mechanism that could be used
> >   I'm sorry, I don't follow here - what can the uart queueing be used for?
> 
> Alan, I'm desperate to avoid adding all this complexity to core printk
> code to solve such a rare problem.  It'd be great if you could flesh out
> any alternative ideas please.

It's not worth adding for upstream anyway - not in that form. If it just
used schedule_work it would be way way cleaner anyway.

For the general buffering case we already have tty_write_message(). It's
only really intended for use by the old quota code so it's currently
assuming nul terminated string but thats a trivial detail.

For that matter I don't see why such systems can't implement a queuecon
console which is a queue on the printk side and a fifo on the userspace
side.

The implementation then becomes trivial.

If you want reliable crash logging then we need to be able to set a
printk level mask per console and just set the serial console for
"crit/err" and the queue console for the rest, with a 'cat
>/dev/ttywhatever' running if this feature was in use ?

Alan

  reply	other threads:[~2014-04-22 10:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-25 17:54 [PATCH 0/8 v4] printk: Cleanups and softlockup avoidance Jan Kara
2014-03-25 17:54 ` [PATCH 1/8] printk: Remove outdated comment Jan Kara
2014-03-25 17:54 ` [PATCH 2/8] printk: Release lockbuf_lock before calling console_trylock_for_printk() Jan Kara
2014-04-23 20:56   ` Andrew Morton
2014-04-24 10:18     ` Jan Kara
2014-03-25 17:54 ` [PATCH 3/8] printk: Enable interrupts " Jan Kara
2014-03-25 17:54 ` [PATCH 4/8] printk: Remove separate printk_sched buffers and use printk buf instead Jan Kara
2014-05-05 18:37   ` Steven Rostedt
2014-03-25 17:54 ` [PATCH 5/8] printk: Hand over printing to console if printing too long Jan Kara
2014-03-25 17:54 ` [PATCH 6/8] printk: Start printing handover kthreads on demand Jan Kara
2014-03-26 17:16   ` One Thousand Gnomes
2014-03-26 19:06     ` Jan Kara
2014-03-25 17:55 ` [PATCH 7/8] kernel: Avoid softlockups in stop_machine() during heavy printing Jan Kara
2014-03-25 17:55 ` [PATCH 8/8] printk: Add config option for disabling printk offloading Jan Kara
2014-03-26 17:23   ` One Thousand Gnomes
2014-03-26 19:28     ` Jan Kara
2014-04-18 18:54       ` Andrew Morton
2014-04-22 10:22         ` One Thousand Gnomes [this message]
2014-04-23 11:08           ` Jan Kara
2014-04-23 12:35             ` One Thousand Gnomes
2014-04-23 14:29               ` Jan Kara
2014-04-23 18:17             ` Andrew Morton
2014-04-23 21:16               ` One Thousand Gnomes
2014-04-23 21:41                 ` Jiri Kosina
2014-04-24 14:00                   ` One Thousand Gnomes
2014-05-15 21:28               ` Jan Kara
2014-04-23  9:30         ` Jan Kara
2014-04-08 14:27 ` [PATCH 0/8 v4] printk: Cleanups and softlockup avoidance Jan Kara
2014-04-08 19:02   ` Andrew Morton
  -- strict thread matches above, loose matches on Subject: below --
2014-03-14 16:21 [PATCH 0/8 v3] " Jan Kara
2014-03-14 16:21 ` [PATCH 8/8] printk: Add config option for disabling printk offloading 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=20140422112259.5f106a44@alan.etchedpixels.co.uk \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pmladek@suse.cz \
    --cc=rostedt@goodmis.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.