Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp732071pxb; Tue, 2 Feb 2021 17:01:26 -0800 (PST) X-Google-Smtp-Source: ABdhPJwS5QU+Otncoagv1SdPPwU99XQu1zX9KLm75mNWZCR/AWcZmsQCcmuoDDmym6D8vjCN795g X-Received: by 2002:a17:906:5002:: with SMTP id s2mr666273ejj.16.1612314086775; Tue, 02 Feb 2021 17:01:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612314086; cv=none; d=google.com; s=arc-20160816; b=c1F8O306MWGhyhVZFW6RhzUBup5z4B9xQRB0a2dlx6Y8zU1dYt1G3vGWJLYqRd+Ztr YuCOQXcPjq+Y07IhqSv5PKYAC257APaDC6YucDy70hK51KFGCGCKJLW5jcwwGItpuIZk teX3GnoSRWSSJ2W5Zeu4masfhL3KFXbvwNVThwl004yGhVLjAYXRcR1z8FFKwOYVFU0p CcK9Ubt2zfxrBngIACmZ2LAEyfF85HM5C3aiqu8RmwI69F0F5w9zy6Ojy+B9nw5HoDbp +T2FAJLifX6B/vHHiVQo1Wtg60nSEm81OTkRR/xw24UoAUhYCrx3+5AXykN9znaSmHz/ Y+mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=UGA0Rplim8ZfC6e4whP20xTht9RzqhbWWxLaXhzWRUA=; b=eiu5oUMOpH6NdSSGQCnUnt2Au49v5X73bEFQeAJwB/S/IlnCl5H7nxfbNhyL/o9Svi Vp8mzsuAjqBZ4QEKOY/HKw0twTXy9qfp9LB0IpW8lRyMJNiO86hLiQYWJwWiDfLcJFPF XjvqoZkGrtxJ7vD9U15k4hj1ZZ6cdO+9b2N9FPo96csa1U5hCwMNGHRwGjn2SD5pABo3 lZmKBS1V8b3NJ6M12lZ/Fr0GTqAF7mvhmPl/IF2VpNZfSET4zGZuny/klWXMlj7gIRE3 ivlxSebQzvnZPYiuPRyQLjk1D7pQJjublzs/ZgBOaeYaR1etjN3MxB7yKIgDuD0/t+wN Najg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=tOBe0hEH; 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=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id s19si317192ejd.463.2021.02.02.17.01.02; Tue, 02 Feb 2021 17:01:26 -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=@nifty.com header.s=dec2015msa header.b=tOBe0hEH; 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=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236049AbhBBXF5 (ORCPT + 99 others); Tue, 2 Feb 2021 18:05:57 -0500 Received: from conssluserg-05.nifty.com ([210.131.2.90]:22160 "EHLO conssluserg-05.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233050AbhBBXF4 (ORCPT ); Tue, 2 Feb 2021 18:05:56 -0500 X-Greylist: delayed 57464 seconds by postgrey-1.27 at vger.kernel.org; Tue, 02 Feb 2021 18:05:53 EST Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (authenticated) by conssluserg-05.nifty.com with ESMTP id 112N4khF003133; Wed, 3 Feb 2021 08:04:46 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-05.nifty.com 112N4khF003133 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1612307086; bh=UGA0Rplim8ZfC6e4whP20xTht9RzqhbWWxLaXhzWRUA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tOBe0hEHHf9tvmT3rHNnjBL9ugZuudIECWVtYvCik/AC2pP1I4bqBET4RIJ/vBKSB 0aRw/i7F91TD/PzkclnU2rVRXFMEw6JAzCx93I17/rKXeFG7l0py1WRGJG2fQCZQLj q99jD6spPDWOLAzyv0+yHJdvetuJ0mv8N9l2T+24C2KTXwMzAOnAFXBCq1xn8EfdZh EqvYL29bZ/OMZE6jEBXdHTulk62/GRSs0uLVCRks7bcTqFsH9kUUbnniWFdepR5nay nVRHIn7crbFdyzki6dQc69GxxIU1dobMhHCeavZav8fqc5flWT+QiFEmuYa9o3WH3Q 4bzZRX2Ms/k9g== X-Nifty-SrcIP: [209.85.214.177] Received: by mail-pl1-f177.google.com with SMTP id u11so13344353plg.13; Tue, 02 Feb 2021 15:04:46 -0800 (PST) X-Gm-Message-State: AOAM532yuR3F6Vl6z+NNFjFuGpuWcQl1WLAEmHtTkrLsMp8b4+WdKjrw hQrJrSp9A9DIdg9f51DuZe3ED7EZv7t5beQT7aU= X-Received: by 2002:a17:90b:1b50:: with SMTP id nv16mr88481pjb.153.1612307085830; Tue, 02 Feb 2021 15:04:45 -0800 (PST) MIME-Version: 1.0 References: <20210202070218.856847-1-masahiroy@kernel.org> In-Reply-To: From: Masahiro Yamada Date: Wed, 3 Feb 2021 08:04:08 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/3] printk: use CONFIG_CONSOLE_LOGLEVEL_* directly To: Sergey Senozhatsky Cc: Linux Kernel Mailing List , Petr Mladek , Steven Rostedt , John Ogness , 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 , linux-efi , Linux Fbdev development list , platform-driver-x86@vger.kernel.org, X86 ML Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 2, 2021 at 7:09 PM Sergey Senozhatsky wrote: > > On (21/02/02 16: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. > > Do you change CONFIG_CONSOLE_LOGLEVEL_DEFAULT so often that it becomes a > problem? > > -ss is one of most included headers, so it is worth downsizing. CONSOLE_LOGLEVEL_DEFAULT is not such a parameter that printk() users need to know. Changing CONFIG_CONSOLE_LOGLEVEL_DEFAULT results in the rebuilds of the entire tree, which is a flag of bad code structure. So, this is not only CONSOLE_LOGLEVEL_DEFAULT. contains parameters and func declarations that printk() users do not need to know. Examples: CONSOLE_LOGLEVEL_DEFAULT log_buf_addr_get() log_buf_len_get() oops_in_progress ... They are only needed for those who want to more closely get access to the printk internals. Ideally, such parameters and func declarations can go to the subsystems' local header (kernel/printk/internal.h) but when it is not possible, they can be separated out to a different header. I can see a similar idea in the consumer/provider model in several subsystems. Consumers and providers are often orthogonal, and de-coupling them clarifies who needs what. See other subsystems, for example, - clk consumer - clk provider -- Best Regards Masahiro Yamada