[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20161104160640.GC422@swordfish>
Date: Sat, 5 Nov 2016 01:07:13 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Jan Kara <jack@...e.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Joe Perches <joe@...ches.com>, Jiri Kosina <jikos@...nel.org>,
Theodore Tso <tytso@....edu>, Hannes Reinecke <hare@...e.de>,
Jan Kara <jack@...e.com>, Petr Mladek <pmladek@...e.com>,
linux-kernel@...r.kernel.org
Subject: Re: printk considered harmful (was: [TECH TOPIC] asynchronous printk)
Hi Jan,
On (11/04/16 00:28), Jan Kara wrote:
[..]
> > I'm still not entirely sure if I want to split async pintk and printk
> > deadlock rework. these things want to come together, for a number of
> > reasons. or, at least, push the async printk before printk deadlock
> > rework.
>
> Yep, please push async printk patches soon. IMHO there's no reason to wait
> with that. You can create a git tree with printk patches and push it directly
> to Linus since he seems to be fine with the approach...
I'll merge async printk and printk_deferred() patches in one patch set
and then push it (it's just one extra patch in the series; besides we touch
wake_up_klogd_work_func() in async printk anyway), since they really want to
come together. and before async+deferred work I want to push printk_safe. we
already have a somewhat bad experience with printk recursion in async printk,
so I want to stay on the safe side this time.
and, yes, I had this idea of having a printk tree somewhere on github,
so people can start playing with it.
thanks.
-ss
Powered by blists - more mailing lists