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: <YZzHoKLznX95p23v@alley>
Date:   Tue, 23 Nov 2021 11:51:12 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <senozhatsky@...omium.org>
Cc:     John Ogness <john.ogness@...utronix.de>,
        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 Tue 2021-11-23 11:15:52, Sergey Senozhatsky wrote:
> 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".

By "new console" I mean the console that is passed being registered.
It is the console passed by @newcon parameter.

In compare, @preferred_console is only one. It is the last non-braille
consoles added by __add_preferred_console().

Outlook:

I have a followup patch set that renames @console_cmdline[] to
@preferred_consoles[]. The array includes consoles that are preferred
also by the device tree or SPCR. It is not only by the command line.

The patch also renames @preferred_console to @last_preferred_console.
It helps to distinguish it from the array name. Anyway, the last
console is just one of the preferred consoles. It is special only
because it should get associated with /dev/console.

The renaming causes a lot of noise. I am not sure if it is worth it.
It is currently done as the very last step (23rd patch) after
the rest of the logic is cleaned. But if you like it. I could
do it earlier.

Thanks for review.

Best Regards,
Petr