Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935084AbdDFODA (ORCPT ); Thu, 6 Apr 2017 10:03:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:45141 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934408AbdDFOCy (ORCPT ); Thu, 6 Apr 2017 10:02:54 -0400 Date: Thu, 6 Apr 2017 16:02:51 +0200 From: Petr Mladek To: Calvin Owens Cc: Sergey Senozhatsky , Steven Rostedt , Greg Kroah-Hartman , Jiri Slaby , Andrew Morton , Manuel =?iso-8859-1?Q?Sch=F6lling?= , Hans de Goede , Paul Burton , linux-kernel@vger.kernel.org, kernel-team@fb.com, Sergey Senozhatsky Subject: Re: [RFC][PATCH 1/2] printk: Introduce per-console filtering of messages by loglevel Message-ID: <20170406140251.GC27578@pathway.suse.cz> References: <20170405020800.GB11669@jagdpanzerIV.localdomain> <20170405021628.GC11669@jagdpanzerIV.localdomain> <20170405152256.GS3452@pathway.suse.cz> <20170406003819.dgbkdixvh6tn7hk5@Haydn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170406003819.dgbkdixvh6tn7hk5@Haydn> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3991 Lines: 110 On Wed 2017-04-05 17:38:19, Calvin Owens wrote: > On Wednesday 04/05 at 17:22 +0200, Petr Mladek wrote: > > I think about a reasonable behavior. There seems to be three variables > > that are related and are in use: > > > > console_level > > minimum_console_loglevel > > ignore_loglevel > > > > The functions seems to be the following: > > > > + console_level defines the current maximum level of > > messages that appear on all enabled consoles; it > > allows to filter out less important ones > > > > + minimum_console_loglevel defines the minimum > > console_loglevel that might be set by userspace > > via syslog interface; it prevents userspace from > > hiding emergency messages > > > > + ignore_loglevel allows to see all messages > > easily; it is used for debugging > > > > IMPORTANT: console_level is increased in some special > > situations to see everything, e.g. in panic(), oops_begin(), > > __handle_sysrq(). > > > > I guess that people want to see all messages even on the slow > > console during panic(), oops(), with ignore_loglevel. It means > > that the new per-console setting must not limit it. Also any > > console must not go below minimum_console_level. > > I can definitely take oops_in_progress and minimum_console_level into > account in the drop condition. I can also send a patch to make the sysrq > handler reset all the maxlevels to LOGLEVEL_DEBUG if you like. Please note that you must not call console_lock() in the sysrq handler. The function might sleep and it is irq context. By other words, you could not manipulate the console structures there. > > What about doing it the other way and define min_loglevel > > for each console. It might be used to make selected consoles > > always more verbose (above current console_level) but it > > will not limit the more verbose modes. > > I think it's more intuitive to let the global sysctl behave as it always > has, and allow additional filtering of higher levels downstream. I can > definitely see why users might find this a bit confusing, but IMHO > stacking two "filters" is more intuitive than a "filter" and a "bypass". I do not have strong opinion here. I like the idea of this patch. Sadly, the console setting already is pretty confusing. I know that many people, including me, have troubles to understand the meaning of the 4 numbers in /proc/sys/kernel/printk. They set console_loglevel default_message_loglevel minimum_console_loglevel default_console_loglevel And we are going to add another complexity :-( > How about a read-only "functional_loglevel" attribute for each console > that displays: > > max(min(console_level, con->maxlevel), minimum_console_level) I like this idea and it inspired me. What about creating the following structure under /sys /sys/consoles//loglevel /minimum_loglevel //loglevel /minimum_loglevel /loglevel /minimum_loglevel The semantic would be: + global loglevel will show the current default console_loglevel, it must be above the global minimum_console_loglevel + the per-console loglevel will show the loglevel specific for the given console; it must be above the per-console minimum_loglevel while + the per-console minimum_loglevel must be above the global minimum_console_loglevel The setting of the global values would affect the per-console values but it must respect the above rules. It is still the "filter" and "bypass" logic. But we will just repeat the existing terms and logic. Also note that "ignore_loglevel" and the special modes in sysrq, panic, oops use the "bypass" logic as well. > Would that make the semantics more obvious? I'll obviously also send > patches for Documentation once there's consensus about the interface. Please add also linux-api@vger.kernel.org, especially for the patch adding the new toplevel directory under /sys. Best Regards, Petr