Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   John Ogness <john.ogness@linutronix.de>
To:     David Laight <David.Laight@ACULAB.COM>,
        'Joe Perches' <joe@perches.com>,
        Linus Torvalds <torvalds@linux-foundation.org>
Cc:     Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [RFC PATCH 1/5] printk: implement pr_cont_t
In-Reply-To: <389a62f178d2482b9525f499b82e92df@AcuMS.aculab.com>
References: <20200819232632.13418-1-john.ogness@linutronix.de> <20200819232632.13418-2-john.ogness@linutronix.de> <e1e3164eabf69e04ad9e9ddc259ca685f48c5e27.camel@perches.com> <b17fc8afc8984fedb852921366190104@AcuMS.aculab.com> <29b6120680fbfb51936bb9100b2c9bb78385aef0.camel@perches.com> <389a62f178d2482b9525f499b82e92df@AcuMS.aculab.com>
Date:   Thu, 20 Aug 2020 11:24:33 +0206
Message-ID: <87wo1tzndi.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 2020-08-20, David Laight <David.Laight@ACULAB.COM> wrote:
>> On Thu, 2020-08-20 at 07:44 +0000, David Laight wrote:
>>> I've no idea how you'd 'size' the number of buffers.
>> 
>> I believe they are static and assume no more than 10
>> simultaneous uses of printk_begin
>
> What I meant was how you'd work out whether 10 was in any way
> appropriate.  ISTM it is either 'too many' or 'nowhere near enough'
> depending on exactly what the system is doing.

Right now mainline has 1, which breaks pr_cont just booting your system.

I expect we will be increasing the number of buffers, regardless if we
adapt a new API or continue with what we have now.

> And if code 'leaks' them you are in deep doo-doos.

Not really. It falls back to printing individual parts. Also, the printk
subsystem has access to the open buffers and could even track the users
lockdep style.

But this discussion has little to do with the API. These are
implementation details that may end up under the hood of the current
mainline API.

John Ogness