From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752703AbcCJPuc (ORCPT <rfc822;w@1wt.eu>);
	Thu, 10 Mar 2016 10:50:32 -0500
Received: from mail-pa0-f41.google.com ([209.85.220.41]:36215 "EHLO
	mail-pa0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750907AbcCJPuZ (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 10 Mar 2016 10:50:25 -0500
Date: Fri, 11 Mar 2016 00:48:15 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
        akpm@linux-foundation.org, jack@suse.com, pmladek@suse.com,
        tj@kernel.org, linux-kernel@vger.kernel.org,
        sergey.senozhatsky@gmail.com
Subject: Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async
Message-ID: <20160310154815.GA567@swordfish>
References: <201603061618.GED43232.MtOQOFSLOFHJFV@I-love.SAKURA.ne.jp>
 <20160306093530.GA26055@swordfish>
 <201603062006.IJD17667.OOQFLtMVHOFSJF@I-love.SAKURA.ne.jp>
 <20160306132703.GA927@swordfish>
 <20160307082230.GB5201@quack.suse.cz>
 <20160307101233.GA10690@swordfish>
 <20160307105248.GF5201@quack.suse.cz>
 <20160307121625.GG5201@quack.suse.cz>
 <20160309060950.GA666@swordfish>
 <20160310092749.GE5026@quack.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160310092749.GE5026@quack.suse.cz>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On (03/10/16 10:27), Jan Kara wrote:
[..]
> So I think this should definitely stay as a separate patch since it
> possibly changes user visible behavior and sometimes blocking may be
> actually desirable for userspace. I don't have that strong opinion whether
> it should be in a separate patch set or part of this one. Maybe a separate
> patch set would be somewhat better so that we first hash out possible issues
> with async printk and once that's settled we start messing more with the
> code changing the behavior of console_unlock() as well.

agree, thanks. I'll split the series and submit console_unlock() rework
separately.

	-ss