Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
From:   John Ogness <john.ogness@linutronix.de>
To:     Sergey Senozhatsky <senozhatsky@chromium.org>
Cc:     Petr Mladek <pmladek@suse.com>,
        Sergey Senozhatsky <senozhatsky@chromium.org>,
        Steven Rostedt <rostedt@goodmis.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-kernel@vger.kernel.org, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH printk v1] printk: fix illegal pbufs access for
 !CONFIG_PRINTK
In-Reply-To: <20230921021859.GA14418@google.com>
References: <20230920155238.670439-1-john.ogness@linutronix.de>
 <20230921021859.GA14418@google.com>
Date:   Thu, 21 Sep 2023 09:19:44 +0206
Message-ID: <87led0f17b.fsf@jogness.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On 2023-09-21, Sergey Senozhatsky <senozhatsky@chromium.org> wrote:
> I wonder if anyone really use !PRINTK kernels. Can we get rid
> of CONFIG_PRINTK?

It is used. It is one of the big annoyances during the last several
years of the rework. I get bug reports relatively quickly after breaking
!CONFIG_PRINTK. The reports come mostly from the kbuild robots, but also
from real people.

If someone has limited space/memory requirements and does not care about
dmesg, they can save a considerable amount of kernel size and memory by
turning all that off. The problem right now is that !CONFIG_PRINTNK is
horribly hacked together with dummy implementations and useless real
functions that pretend to do stuff.

After the rework we can work on splitting out the code based on
functionality. If done right, it will be trivial to "implement"
!CONFIG_PRINTK in such a way that changes to real code don't explode
every time on !CONFIG_PRINTK.

John