Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp9001148rwb; Thu, 24 Nov 2022 06:57:15 -0800 (PST) X-Google-Smtp-Source: AA0mqf6x6422JZ2xjkURj4W1enEvcDOSGcXJ2NyYpfEFwhMjKLmxr+Rz6wI1aVmVaxCEC/MfSRMX X-Received: by 2002:a17:90a:7183:b0:212:ede4:3c19 with SMTP id i3-20020a17090a718300b00212ede43c19mr36496029pjk.151.1669301834898; Thu, 24 Nov 2022 06:57:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669301834; cv=none; d=google.com; s=arc-20160816; b=eoiW0USH6MsDsO9J2OVDInictD6cTk/9L1oxuncEqCfs8Z5MzdsLDKls5vqCTLADfH CvAL3Ar4iugmtWIE2vqSTkURBqlNe/+ROZt7EWD2udzPUiVwX10bGbckoILed0fnlzfc Bjs3Q2nBzoJH6WjKWVgo6MCsPaP7ON92G9FRDNeiQnX/pnxphKrcZnVC+45IwKEu9Y8K r1iA63ctxhIS8O3jIHha0CjEVngaf5jGoZnMmzLib7VEQkSib+GnTkrnGbw4N3YlNsbT iGNLSzQ9XMLVeiTM6qzEX1uY8BxFC+XLQZVUiiWhFR+MaPGS1M0MIz9VQ7dnHLy+mozi NMbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=tnDrkdSii3PCQmNaq62QSyqQxDKrs3bL6M/dlK4fjjs=; b=cHWG/L2weMrlFjKzFt9alL4YwKTVLuIn9xYMvHSkt7s/eh9po42KmySonxm6Nf0qZ3 fx9ek01iPCJNB0/G87dBVPgNCjtDNmYmGpOPlsEWNWAt2NCkV1TEmY/I9ZbyGBilJR/X 8MeVhSrJS4cBNPjr/J6t9KFIT4pXKcEcTM0BbLOntKw/HPHr3Cb4y63QTgBrPCP6jfv0 lqYhnOYLyw14BwmVoBQbG556sucHQ30VAUNQNgaR009VYcSKuubxjukNi5+FHgH0dBsT 1Q9IlK91eKiubobsXgLee33sYfNGqctIvDworcHb8YYff2CxN8a9nJrwjCNMmB6RD4E+ pPdw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=o+cE67B7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id oj15-20020a17090b4d8f00b00212e4f65e71si5348460pjb.31.2022.11.24.06.57.03; Thu, 24 Nov 2022 06:57:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=o+cE67B7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229533AbiKXOm7 (ORCPT + 87 others); Thu, 24 Nov 2022 09:42:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46168 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229476AbiKXOm6 (ORCPT ); Thu, 24 Nov 2022 09:42:58 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8F7363BA5 for ; Thu, 24 Nov 2022 06:42:55 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 85E301F8B3; Thu, 24 Nov 2022 14:42:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1669300974; h=from:from:reply-to: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=tnDrkdSii3PCQmNaq62QSyqQxDKrs3bL6M/dlK4fjjs=; b=o+cE67B786QAeQFF+VBHFx7k+oB8iBjL7yJM2rLqmSCzSAdmqcUFuX91X8rXvBXQZebcnP AVBMdNtngGxyyHM7XEPRuCvESQWw7bfWbc0LhWREbEQF/OdLSzO8ci7Lfqw0NvEDr9+aP8 OpKHU9QRq69fpHCa1bLu9QcOQ2PjuRY= Received: from suse.cz (unknown [10.100.201.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 5507B2C142; Thu, 24 Nov 2022 14:42:54 +0000 (UTC) Date: Thu, 24 Nov 2022 15:42:53 +0100 From: Petr Mladek To: John Ogness Cc: Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , linux-kernel@vger.kernel.org, Greg Kroah-Hartman Subject: Re: [PATCH printk v2 1/7] printk: Move buffer size defines Message-ID: References: <20221123231400.614679-1-john.ogness@linutronix.de> <20221123231400.614679-2-john.ogness@linutronix.de> <87zgcgttmi.fsf@jogness.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zgcgttmi.fsf@jogness.linutronix.de> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 2022-11-24 13:44:29, John Ogness wrote: > On 2022-11-24, Petr Mladek wrote: > >> Move the buffer size defines to console.h in preparation of adding a > >> buffer structure. The new buffer structure will be embedded within > >> struct console. Therefore console.h was chosen as the new home for > >> these defines. > > > > The buffers are not embedded into struct console in this patchset. > > Are they going to be added directly or via pointer, please? > > By "embedded" I mean added directly. The buffers need to be available > immediately and cannot be allocated or assigned dynamically. The console > struct is generally defined by drivers with: > > static struct console my_console = { > ... > }; > > I could think of no way to statically define the buffers but keep their > sizes hidden. > > > IMHO, it is always better to hide these implementation details > > in an internal header or source file. It will be possible > > if struct console contained on a pointer to the buffers. > > The problem is not pointers, it is static definition (without knowing > the size of the thing that is statically defined). The new thread/atomic > consoles run in parallel, so they cannot share the single static buffer > like we do now. Let me to play a devil advocate first: Well, allocation is possible long before scheduling is possible. It is actually available even before early parameters are proceed where the boot consoles are registered. At least it is used when setup_log_buf(1) is called in setup_arch() on x86. The motivation is that only thread/atomic consoles would need the console-specific buffer. The other consoles might share the global one. It would be useful even for atomic consoles. IMHO, most users use generic kernels that support a variety of hardware. They would provide static buffers for many console drivers but only one or two would be used in the end. Also the atomic consoles would need these buffers for each context. It might be even more useful to allocate them dynamically. Or do I miss something, please? That said: I do not have any numbers at hands to show how this is important. Also I do not know if the early allocations have some limits. The static buffers might be acceptable for simplicity and reliability after all. Feel free to keep them static. I would ack the next version of this patch after making the CONSOLE_EXT_LOG_MAX dependent on CONFIG_PRINTK. Best Regards, Petr