linux-kernel - Re: [PATCH 2/5] printk/console: Rename has_preferred_console to need_default

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YZxO2I7D8uFQWKTF@google.com>
Date:   Tue, 23 Nov 2021 11:15:52 +0900
From:   Sergey Senozhatsky <senozhatsky@...omium.org>
To:     Petr Mladek <pmladek@...e.com>
Cc:     John Ogness <john.ogness@...utronix.de>,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] printk/console: Rename has_preferred_console to
 need_default_console

On (21/11/22 14:26), Petr Mladek wrote:
> The logic around the variable @has_preferred_console made my head
> spin many times. Part of the problem is the ambiguous name.
> 
> There is the variable @preferred_console. It points to the last
> non-braille console in @console_cmdline array. This array contains
> consoles preferred via the command line, device tree, or SPCR.
> 
> Then there is the variable @has_preferred_console. It is set to
> "true" when @preferred_console is enabled or when a console with
> tty binding gets enabled by default.
> 
> It might get reset back by the magic condition:
> 
> 	if (!has_preferred_console || bcon || !console_drivers)
> 		has_preferred_console = preferred_console >= 0;
> 
> It is a puzzle. Dumb explanation is that it gets re-evaluated
> when:
> 
> 	+ it was not set before (see above when it gets set)
> 	+ there is still an early console enabled (bcon)
> 	+ there is no console enabled (!console_drivers)
> 
> This is still a puzzle.
> 
> It gets more clear when we see where the value is checked. The only
> meaning of the variable is to decide whether we should try to enable
> the new console by default.

A nit: by "new console" you probably mean preferred_console. It sort
of suggests that try_enable_new_console() was not such a bad name,
may be, since we still refer to such consoles as "new" not "preferred".


> Rename the variable according to the single situation where
> the value is checked.
> 
> The rename requires an inverted logic. Otherwise, it is a simple
> search & replace. It does not change the functionality.
> 
> Signed-off-by: Petr Mladek <pmladek@...e.com>

Reviewed-by: Sergey Senozhatsky <senozhatsky@...omium.org>