Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp493748ybk; Wed, 13 May 2020 05:39:24 -0700 (PDT) X-Google-Smtp-Source: APiQypJAvU4YODxlyRq7p9yqvH5q2JK4ID2ZjzzyvBPfL0+qZHIiZ2WY9raZvSUPFLbEShs93Hzq X-Received: by 2002:a17:907:7242:: with SMTP id ds2mr22827833ejc.297.1589373564540; Wed, 13 May 2020 05:39:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589373564; cv=none; d=google.com; s=arc-20160816; b=W0aBkVoRq8yg/Jl59NsZekijaJn3EwgdKOUEOzhn6FSYYZIXfDwtJwdn7s/ZHolFr8 Xo6VVpio70iY4dHaj2lNcX2lc/PDSrATYSWFYHBYDiAT+NfUCDzcZmouzICEptHu/wJO Kzo7HXBqSu8xmZ8NmwNikqy+LaBtGznXUasDKVTlCllC6w0l409ydLFPkQosvOV2qO5f 2ZoKQtMbJIfZU6yN2r82mINJJrD7XDPF7Vl/FwmkOaXm4TQ0HzAY5iWJeFUCwwFyU08O 68OfnzoEvQ8Mns3RxGRPbKAocaciJnsqMc5ze4g8SDBXhZPXd+Sr+yourQoXCESylwHy gQQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=zg9mFk286fmPvum8cAgmbtg//jMB/k/KAkiXG4jqbHg=; b=FyGA+dUoYvU3sRo9OqR7KGlkRZA+OdvHtYZd2WItyJ2jl/q+B4JzRSxSZvYhWD4JmN UAf8hUWZa0Fb8MHuUsJGTCaOj+7lZsZtBKFGe4PcDT6rqwACZyqzLlA8cByqPJquFzLL JuFhVdhQ4eQY/tI8KsUGMc4O2y6DBTMyiUQBwmUF+M56lEmnNs09YokMZKp0Bb3uhiAF r4sfK2tENWyh7fA1DAhMhtnDhyukn8nNaDFIMvuvIs38H5CdJ8fc6a9/LaBCgEUKryMd +k93hwzDdTWz8v+/ZSpHnNsm9EiIzGsQsdZ4FcMK91DmM/XesC02/N5uU0AqyXV3FmA4 oVgg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d9si5665052ejb.393.2020.05.13.05.39.01; Wed, 13 May 2020 05:39:24 -0700 (PDT) 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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731678AbgEMMew (ORCPT + 99 others); Wed, 13 May 2020 08:34:52 -0400 Received: from mx2.suse.de ([195.135.220.15]:49792 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728726AbgEMMev (ORCPT ); Wed, 13 May 2020 08:34:51 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 6B4B9AA4F; Wed, 13 May 2020 12:34:52 +0000 (UTC) Date: Wed, 13 May 2020 14:34:48 +0200 From: Petr Mladek To: Tetsuo Handa Cc: Sergey Senozhatsky , Michal Hocko , Steven Rostedt , linux-kernel@vger.kernel.org, Dmitry Safonov , Yafang Shao Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles". Message-ID: <20200513123448.GL17734@linux-b0ei> References: <20200428121828.GP28637@dhcp22.suse.cz> <20200428154532.GU28637@dhcp22.suse.cz> <20200429142106.GG28637@dhcp22.suse.cz> <20200513062652.GM413@jagdpanzerIV.localdomain> <20200513100413.GH17734@linux-b0ei> <20564555-7b84-f716-5dcd-978f76ad459a@i-love.sakura.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20564555-7b84-f716-5dcd-978f76ad459a@i-love.sakura.ne.jp> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 2020-05-13 20:03:53, Tetsuo Handa wrote: > On 2020/05/13 19:04, Petr Mladek wrote: > >> What is wrong with adding NO_CONSOLES ? > > > > How does it differ from KERN_DEBUG? The debug messages: > > > > + can be disabled via sysfs > > + might reach console when this loglevel is enabled > > KERN_NO_CONSOLES is different from KERN_DEBUG in that KERN_NO_CONSOLES > itself does not affect userspace daemon's judgement (whether to filter > KERN_$LOGLEVEL messages). And that is the evil thing about it. It goes around the loglevel filtering. The administrator wants to decide what messages are important for him. NO_CONSOLES would mess with this decision. Some messages would suddenly get hidden on console but appear in userspace. Users would need to investigate what the hell is happening. They would need to find the new sysfs knob to restore the expected behavior, etc. I am strongly against this. Please, use the existing loglevels to hide messages on console. Configure your filter to store them in userspace. Best Regards, Petr