Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp126723pxb; Tue, 2 Feb 2021 00:40:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJwl+/dtfHqqhjTXWazxg6Fwsu7nl2oNzht27ofUcFWrn5svpy/YzucuoIfptRPtfDHIMtQ9 X-Received: by 2002:a17:906:e48:: with SMTP id q8mr21130720eji.478.1612255231677; Tue, 02 Feb 2021 00:40:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612255231; cv=none; d=google.com; s=arc-20160816; b=CTIAmzn45uaNpuUtimCjw/VOqUTb++/t++rKilvntYfYQSoyqY7y8Ye6sk8AoMM3L9 2zgvTTzVTBZUo5JSxGcMP8WIvhW/iA+zQFBMZFJVtrvHcm9WKiqynibV57Wc8ejuSRBM Ck+hIhRqKN+eTzMxE0YDDlbma4YzxH2915qiZMI8TZQmPluZEZcoaInJILj2DjSz8l+b y7H0Q6thxswZiJaDdCBaeW38vFZFUsvL+Lq1YFEDvUn++UR1Kxssj4SpAu6fONylECSN QVx97g4kA1zCu2fa0wRvEV4tioa63jkUbkR6ET/LfcIan7g1NmCT/b6Vmqo352rmpu5A lM2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=XSvnQS472UFc97/OveAYELQREPOxJl2PjuSTa4E+Q7A=; b=spXG6VQabqOZWIRWruVton8Dls/CovwhdM0WTCWF0Fyzy/qV26PaiLPc+A5cCPm8dj PwdACoy85/4IdM1eC3MoIVQkaoTh3YAQY3chpVyoA+fJnfQ/hmC3TZLnPK+35HGAHxmy u1uTPMnVaAOP6PWi0fSV/5nLyduebS1SMIGozpLiboQPClqtk7a09gFD0wWXHcaYJmFw UCfYnogSNRkwkZ5RJgZpun3Cn0LyrVjk9egrFA20iI25mPM9m2aJnNk9BP4vUIH47U9t bU0ED1rYWi+DQ1ZY7mM/4DyNpmSKWU9NFx+tS9TQ1aL/iZYwrxpPZPicuzjDDzB+zplx xxWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=fOwUz6oM; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u1si6074928ejr.305.2021.02.02.00.40.05; Tue, 02 Feb 2021 00:40:31 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=fOwUz6oM; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232340AbhBBIjN (ORCPT + 99 others); Tue, 2 Feb 2021 03:39:13 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36774 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231538AbhBBIjG (ORCPT ); Tue, 2 Feb 2021 03:39:06 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E9595C061573; Tue, 2 Feb 2021 00:38:25 -0800 (PST) From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1612255104; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XSvnQS472UFc97/OveAYELQREPOxJl2PjuSTa4E+Q7A=; b=fOwUz6oMsJL1OT+8YKgVu8YLiGerlC6aoRGuk2gj3WQtUgU8QXSFpJ09U58JpJZXEehe+m Qvm+Z3XThUOMXKRyBZB7+bDjUhB+oW1k9PjhHBvhXxRvpDI/pEj0dFjalO7cXIZ6/LmAmw AkIet2SuXwlUKmVKo6LYhbu3DnbqfcXWFnkeq13yZS8SZs/yNjBFd+tbOJ43wrJQMUIO4V V5ZdDZeEV1oaO/ZC+FkkcD5CvM9I9f9RZUMxvlOWWq7jLpmML8ghyP0xcXUniwX4RVQVj4 j9+Q4MQbZrSxNHrqAt2SHlSB53aNx+8ux1oL3D+TPkMNegsaWy31lKKV3ki2GA== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1612255104; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=XSvnQS472UFc97/OveAYELQREPOxJl2PjuSTa4E+Q7A=; b=OPu2XNNKWOUcpfxtFJWAMYFL7d6qcjsZokIJEMUiNGj0vWq2dCutTDGvIHWGet1UOF9hx3 9T+b4TtHpCZ3cXDw== To: Masahiro Yamada , linux-kernel@vger.kernel.org, Petr Mladek , Sergey Senozhatsky , Steven Rostedt Cc: Masahiro Yamada , Andy Shevchenko , Ard Biesheuvel , Borislav Petkov , Darren Hart , Dimitri Sivanich , Greg Kroah-Hartman , "H. Peter Anvin" , Ingo Molnar , Jiri Slaby , Mike Travis , Peter Jones , Russ Anderson , Steve Wahl , Thomas Gleixner , dri-devel@lists.freedesktop.org, linux-efi@vger.kernel.org, linux-fbdev@vger.kernel.org, platform-driver-x86@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 1/3] printk: use CONFIG_CONSOLE_LOGLEVEL_* directly In-Reply-To: <20210202070218.856847-1-masahiroy@kernel.org> References: <20210202070218.856847-1-masahiroy@kernel.org> Date: Tue, 02 Feb 2021 09:44:22 +0106 Message-ID: <87eehy27b5.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-02-02, Masahiro Yamada wrote: > CONSOLE_LOGLEVEL_DEFAULT is nothing more than a shorthand of > CONFIG_CONSOLE_LOGLEVEL_DEFAULT. > > When you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT from Kconfig, almost > all objects are rebuilt because CONFIG_CONSOLE_LOGLEVEL_DEFAULT is > used in , which is included from most of source files. > > In fact, there are only 4 users of CONSOLE_LOGLEVEL_DEFAULT: > > arch/x86/platform/uv/uv_nmi.c > drivers/firmware/efi/libstub/efi-stub-helper.c > drivers/tty/sysrq.c > kernel/printk/printk.c > > So, when you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT and rebuild the > kernel, it is enough to recompile those 4 files. > > Remove the CONSOLE_LOGLEVEL_DEFAULT definition from , > and use CONFIG_CONSOLE_LOGLEVEL_DEFAULT directly. With commit a8fe19ebfbfd ("kernel/printk: use symbolic defines for console loglevels") it can be seen that various drivers used to hard-code their own values. The introduction of the macros in an intuitive location (include/linux/printk.h) made it easier for authors to find/use the various available printk settings and thresholds. Technically there is no problem using Kconfig macros directly. But will authors bother to hunt down available Kconfig settings? Or will they only look in printk.h to see what is available? IMHO if code wants to use settings from a foreign subsystem, it should be taking those from headers of that subsystem, rather than using some Kconfig settings from that subsystem. Headers exist to make information available to external code. Kconfig (particularly for a subsystem) exist to configure that subsystem. But my feeling on this may be misguided. Is it generally accepted in the kernel that any code can use Kconfig settings of any other code? John Ogness