Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   John Ogness <john.ogness@linutronix.de>
To:     Petr Mladek <pmladek@suse.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        linux-kernel@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH v1] printk: Declare log_wait as external variable
References: <20200203131528.52825-1-andriy.shevchenko@linux.intel.com>
        <20200211124317.x5erhl7kvxj2nq6a@pathway.suse.cz>
        <20200212013133.GB13208@google.com>
        <20200212140355.56drih2wfcryjjtl@pathway.suse.cz>
Date:   Wed, 12 Feb 2020 15:24:44 +0100
In-Reply-To: <20200212140355.56drih2wfcryjjtl@pathway.suse.cz> (Petr Mladek's
        message of "Wed, 12 Feb 2020 15:03:55 +0100")
Message-ID: <8736bfdgsz.fsf@linutronix.de>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2020-02-12, Petr Mladek <pmladek@suse.com> wrote:
> I would prefer to split it:
>
>     + printk.c is already too big and would deserve splitting.
>
>     + The two different kmgs interfaces are confusing on its
>       own. IMHO, it will be even more confusing when they
>       live in one huge source file.
>
>
>> I can take a look at dev_ksmg.c/proc_kmsg.c option, unless
>> someone else wants to spend their time on this.
>
> It would be lovely from my POV. I am only concerned about
> the lockless printk() stuff. I would prefer to avoid creating
> too many conflicts in the same merge window. Well, I am
> not sure how many conflicts there would be. Adding John
> into CC.

I would also love to see these changes. But can we _please_ focus on the
lockless printk ringbuffer merge first? The patches already exist and
are (hopefully) being reviewed. I would prefer that such a heavy API
replacement is done _before_ we start any massive refactoring.

John Ogness