From: Petr Mladek <pmladek@suse.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-kernel@vger.kernel.org,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Andrew Morton <akpm@linux-foundation.org>,
bcm-kernel-feedback-list@broadcom.com,
linux-rpi-kernel@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] printk: remove BOOT_PRINTK_DELAY config
Date: Tue, 5 May 2026 15:54:57 +0200 [thread overview]
Message-ID: <afn2sYKKsqG4QBVX@pathway.suse.cz> (raw)
In-Reply-To: <20260503214214.3475670-1-rdunlap@infradead.org>
On Sun 2026-05-03 14:42:14, Randy Dunlap wrote:
> This boot option is ancient and probably not being used.
> Dave Jones used it successfully maybe 15 years ago...
> AFAIK it doesn't work reliably, especially on SMP.
I agree that it most likely does not have many users and is not
reliable.
In addition, it was kind of obsoleted by printk_delay() which
does very similar thing except that it can only be set
at runtime via sysctl.
Which brings an idea. What about doing the obsoleting properly?
I mean to:
1. Add "printk_delay" early_param() which would allow
to set "printk_delay_msec" via command line.
2. Modify boot_delay_setup() to set "printk_delay_msec" as well.
In addition, it might print a message that it has been
obsoleted by "printk_delay" and will be removed.
Would you mind to do it this way, please?
Regarding the reliability, it might get improved by moving the delay
to console handling code. It would even allow to use sleeping wait
when the consoles are handled in kthreads. But the wait might
get multiplied when more consoles are registered and proceed
on the same CPU. Anyway, this is out of scope for this patch.
Best Regards,
Petr
prev parent reply other threads:[~2026-05-05 13:55 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-03 21:42 [PATCH] printk: remove BOOT_PRINTK_DELAY config Randy Dunlap
2026-05-05 13:54 ` Petr Mladek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=afn2sYKKsqG4QBVX@pathway.suse.cz \
--to=pmladek@suse.com \
--cc=akpm@linux-foundation.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=john.ogness@linutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rpi-kernel@lists.infradead.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=senozhatsky@chromium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox