Re: [PATCH v4 04/11] printk: Separate code for adding/updating preferred console metadata

[Petr Mladek]

On Tue 2026-07-14 16:41:05, John Ogness wrote:
> On 2026-06-04, Petr Mladek <pmladek@xxxxxxxx> wrote:
> > The logic for adding or updating a preferred console is currently
> > duplicated within __add_preferred_console(), making the code difficult
> > to follow and prone to consistency issues.
> >
> > Introduce update_preferred_console() to centralize the initialization
> > and updating of struct preferred_console entries. This refactoring
> > explicitly defines and enforces the following rules:
> >
> > 1. Console names and/or indexes are not set when a console is preferred
> >    via devname; these are resolved later during device matching.
> > 2. Console names are only added alongside a valid index.
> > 3. Only matching entries are updated.
> > 4. Console and Braille options are never cleared. They are updated
> >    only via the command line.
> > 5. The global 'preferred_dev_console' index and 'console_set_on_cmdline'
> >    flag are updated consistently.
> >
> > Additionally, rename braille_set_options() to braille_update_options()
> > to better reflect its conditional behavior.
> >
> > Behavior change:
> >
> > The original code never updated the preferred console options
> > when it was preferred more times, e.g. via the command line
> > and/or some platform specific code, e.g. SPCR or device tree.
> >
> > The new code explicitly allows to update the console options
> > when they are preferred over the command line.
> >
> > It mostly worked even before but only because the command line was
> > processed early enough before handling SPCR, device tree, or other
> > platform specific init code.
> 
> As you previously mentioned, this is a recipe for regressions. IMHO the
> real issue is not that the behavior is changed, but rather that there is
> no official ordering for SPCR/DT/command-line across all platforms.
>
> Also, although a later specification can override previous options, it
> cannot clear them.

Good point!

> I am just wondering if the previous behavior should be preserved until
> someone implements a full solution with proper official option ordering
> and override capabilities.

Hmm, this patch was supposed to define some sane rules. For example,
options defined on the command line would be used even when
the same console was first added, e.g. by SPCR code without options.

Or at least it looked ugly to keep the original behavior.

But maybe, it was not that good idea:

  + It is always a bad idea to "hide" behavior changes into
    a patch which primary does "just" a code clean up.

  + We need to be careful when adding new rules. And it might
    need longer discussion.

I am going to keep the original behavior in v5. And likely even leave
the behavior change for another patchset.

Best Regards,
Petr