[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191211053505.GO88619@google.com>
Date: Wed, 11 Dec 2019 14:35:05 +0900
From: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
linux-kernel@...r.kernel.org, Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC/PATCH] printk: Fix preferred console selection with
multiple matches
On (19/12/11 15:02), Benjamin Herrenschmidt wrote:
> On Wed, 2019-12-11 at 11:01 +0900, Sergey Senozhatsky wrote:
> > On (19/12/11 09:26), Benjamin Herrenschmidt wrote:
> >
[..]
> > If we could perform simple alias matching, without ->setup() call, and
> > exact matching (strcmp()), and then, if newcon would match two entries,
> > we would pick up the last matching entry and configure newcon only once.
> >
> > This changes the order, tho.
>
> Walking the array backwards might just be what we want actually for the
> case at hand, but of course if some platforms or driver call
> add_preferred_console *after* the command line parsing, then it will
> break those.
Reverse loop sounds like a nice idea. But yes I guess this can break
things.
> Simple alias matching would require re-working all the match()
> callbacks. That said I think it was a mistake to begin with to have
> them include setup(). Those should have remained separate.
Agreed. strcmp(alias) and strcmp(exact name) are the same things.
The latter does "match" and setup() as separate steps, but the former
does both at once.
> What about a compromise here:
>
> Instead of walking the array and testing for preferred_console as we do
> so, we first test the array entry pointed to by preferred_console
> (doing both match & setup as today) and if that doesn't work, fallback
> to our existing mechanism ?
This may do the trick.
And perform preferred_console fast-path configuration only if
`has_preferred' is false.
> > Well, it still looks to me that what you want is to "ignore alias
> > match and prefer exact match".
>
> We don't want to ignore the alias match. But we do want to prefer the
> exact match. We still want to keep the fallback to the alias match.
Yeah, "prefer" is the key word here.
-ss
Powered by blists - more mailing lists