From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CA0FD3CC7F3 for ; Mon, 8 Jun 2026 14:07:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780927669; cv=none; b=oGqp3ZuMneF+yAFf4FkhJPytxnZjZwzICnTiiK99oVfx2YDzQjmDZGwOb4ij+wZbpof5veezi6JeU0NO4Mt8tB+yusSGgZQgvtytD9GV8ckiBb5/DclynGaUgkim2liR+S8qc0TKTwRU0NNoBwsR3iNsipuQjf5fg8wOuD2XMSs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780927669; c=relaxed/simple; bh=lqMFDHllkO2XGzqQx/s0qGBo/R3HqgN5eR0I71keFzA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=RR2D3wYJ9OXy/EUBiowfPHFAEum1uwkwICudv2xNrmpbAhGwZfdiFY6tk9MaMeBncBACQrh5NfHL6/DKEu+t2quS8avgMK1ogMd2e+TFQJwMDwfbLW9R1aJBDprN2lxH0l7x1hGuI2YyB3OZbGbPNRdCtZZKEYTd2kRi71AIdzw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=ObmRHJ7Q; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="ObmRHJ7Q" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-490b12270b3so26259085e9.1 for ; Mon, 08 Jun 2026 07:07:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1780927666; x=1781532466; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=v7NWfcHA0wjAt4NBRQYEf+KO3ie3ZCCu2Li2S83po9c=; b=ObmRHJ7QxAMbFwSeOSv2r9UlrsI3DoG7X1+0FfrkNxJ+DqMBjUcDvCsYBWeXbh2u+I rlIgBFGJyq7TEKjMu2r7Zw2wSfQLV5gWatuwEqPiQVL6DBnWXvKyep8ik+zivJ58hJxn kbLEXht+v1ayu1oKSQgPq5aPq2H4qa1zzXikcTVk6yG9QOIvtscmWh1QvbB+lqYtsKXy uc3D11zaN/iFy6YimEn/zBGSSFHNXbg78LoNzqh0EpfdDnZ0ob/56+xbxUAcoc+PFrRH ZCtuUkF1lGNtlabeDfKO9esVIMkweDHzfL66jYY9AdF2NwJewKOfcY7PGcQRyoNMzt8B reYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780927666; x=1781532466; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=v7NWfcHA0wjAt4NBRQYEf+KO3ie3ZCCu2Li2S83po9c=; b=qQYJ6ktqs2v0ZK+twblqcT29ZU0AbNGiWBrUhk+TOtZfoSkyujIu0CvZWLh53UnM4g M6kNbEQfCs9PhT0FQMARCKGwpvlASGKs7Ru5UMaF9exjnYc6K542LzpEgnS/XCI+XxJU YCdXoc0PJq0xl+F4avwr4qv03HgTqm0jqSf8Y0i4jXTIk9b16m88VEGcjxz6mpwzLW5V M9+/33TILb10jjrcpEpSM/8qpXjSZlh+plQ59ucltBFKphAeXYu1TIaxHVbFw1akni98 eGW7jrLs0w31E1qiCGakDb4uY61kwkLrRSi/p50+jG70tPkR/NagsGzsYjy3wYsok4H8 FU7Q== X-Forwarded-Encrypted: i=1; AFNElJ/CAhM27syljb/fdhM/ILsR3err+2uwtjGp3RTnIc3Dwq8R4mQxuPwUVvBke0tsZBY2L9wDEsKFBELmFb4=@vger.kernel.org X-Gm-Message-State: AOJu0YxmzX6gvMvtVFoKDvUDEEY155yccAbSyBhybq3QCiOyJbSfPJ/w +d6c2ABRcxl1mg8ygdydKLTnMUahIp8zWMHEYE4xsFe94LoYIlLFS0W8yQL7fBDMPB0= X-Gm-Gg: Acq92OGtYZSMQQX785ekoe9p+KyRTVX08wuRrBxcSw385o3Qqwt5C4wNlAN8zMg+/HD nI5xkLbKsIHIOrDDq7EtTfkIVQpTwzuJ4FP8yl60fEl2RLL7z0eitdXv+Tpr0ttNfxz4GhEG228 +xs5PnC2s2o4hv/KYnmbJAiSSzz4dyLO15dGjoJ1k+Rd0s/gqWP3jm01gLxcZzUzudazmzvYbC+ Nnr1IvlbNj22Yww0QrjbGhWPp6L32hWOnx44mMPgbpAkLQMp5tA5XxE+FtrqgP8fR8lNGvnPpbQ 94gW1FvITfwW0chM/xbX3L0AnJ0qV55pAwK5t5xDKYE4vuy16iBKjQGAxOt14696tM9brAWxIh9 Q6cUtEACpoByL28VYG7la/O3CGKeOSysXHSLbkwGr3K+l4UyrXVy36iE0RLCo3kJmnE+EKywtnW Ob9I/vMEJK56vz6ThyoB7PFTa4bPBhWaiOHPLQA+owwkk0Blo= X-Received: by 2002:a05:600c:154c:b0:490:9ea0:c11f with SMTP id 5b1f17b1804b1-490c25afa50mr262456145e9.5.1780927666052; Mon, 08 Jun 2026 07:07:46 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490bc3cc140sm475559525e9.9.2026.06.08.07.07.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 07:07:45 -0700 (PDT) Date: Mon, 8 Jun 2026 16:07:43 +0200 From: Petr Mladek To: Andrew Murray Cc: Jonathan Corbet , Shuah Khan , Russell King , Florian Fainelli , Broadcom internal kernel review list , Ray Jui , Scott Branden , Steven Rostedt , John Ogness , Sergey Senozhatsky , Andrew Morton , Sebastian Andrzej Siewior , Clark Williams , Randy Dunlap , Linus Torvalds , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rpi-kernel@lists.infradead.org, linux-rt-devel@lists.linux.dev Subject: Re: [PATCH RFC 2/4] printk: deprecate boot_delay in favour of printk_delay Message-ID: References: <20260601-deprecate_boot_delay-v1-0-c34c187142a6@thegoodpenguin.co.uk> <20260601-deprecate_boot_delay-v1-2-c34c187142a6@thegoodpenguin.co.uk> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260601-deprecate_boot_delay-v1-2-c34c187142a6@thegoodpenguin.co.uk> On Mon 2026-06-01 00:17:38, Andrew Murray wrote: > The boot_delay (BOOT_PRINTK_DELAY) kernel parameter and printk_delay sysctl > are two distinct mechanisms for providing similar functionality which add a > delay prior to each printed printk message. > > boot_delay provides a kernel parameter for delaying printk output from > kernel start through to boot (SYSTEM_RUNNING), whereas printk_delay is > configurable only via sysctl and thus is only used post boot. > > Let's deprecate the boot_delay feature in favour of printk_delay. In order > to preserve functionality, we'll also extend printk_delay such that it can > additionally configured via a kernel parameter. I would make it clear and say: "via an early kernel parameter". Note that there are also kernel parameters which can be modified at runtime via /sys/module/kernel/paramters/ Also I would make it clear that this changes the behavior, for example: Behavior change: The delay enabled by both "boot_delay" and "printk_delay" continues working even in SYSTEM_RUNNING state. It must be explicitly stopped by setting printk_delay=0 via sysctl. The delay is skipped when the message is suppressed in all system states. It used to skipped only for the boot_delay. > --- a/kernel/printk/printk.c > +++ b/kernel/printk/printk.c > @@ -1339,11 +1327,34 @@ static void boot_delay_msec(int level) > } > } > #else > -static inline void boot_delay_msec(int level) > +static inline void __init printk_delay_calculate(void) > +{ > +} > + > +static inline void early_boot_delay_msec(void) > { It would be nice to print a warning that the early boot delay does not work, something like: pr_warn_once("Early boot delay does not work without CONFIG_GENERIC_CALIBRATE_DELAY enabled.\n"); > } > #endif > > +static int __init printk_delay_setup(char *str) > +{ > + get_option(&str, &printk_delay_msec); > + if (printk_delay_msec > 10 * 1000) > + printk_delay_msec = 0; Sashiko AI warns that this code accepts negative values. It might cause long delays, see https://sashiko.dev/#/patchset/20260601-deprecate_boot_delay-v1-0-c34c187142a6%40thegoodpenguin.co.uk The problem has already been there even before. But it would be nice to fix it. > + > + printk_delay_calculate(); > + > + return 0; > +} > +early_param("printk_delay", printk_delay_setup); > + > +static int __init boot_delay_setup(char *str) > +{ > + pr_warn("boot_delay will soon be deprecated, please use printk_delay instead"); > + return printk_delay_setup(str); > +} > +early_param("boot_delay", boot_delay_setup); > + > static bool printk_time = IS_ENABLED(CONFIG_PRINTK_TIME); > module_param_named(time, printk_time, bool, S_IRUGO | S_IWUSR); Otherwise, it looks good to me. Best Regards, Petr