[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200129134141.GA537@jagdpanzerIV.localdomain>
Date: Wed, 29 Jan 2020 22:41:41 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 5/5] console: Introduce ->exit() callback
On (20/01/28 11:44), Andy Shevchenko wrote:
> > If the console was not registered (hence not enabled) is it still required
> > to call ->exit()? Is there a requirement that ->exit() should handle such
> > cases?
>
> This is a good point. The ->exit() purpose is to keep balance for whatever
> happened at ->setup().
>
> But ->setup() is being called either when we have has_preferred == false or
> when we got no matching we call it for all such consoles, till it returns an
> error (can you elaborate the logic behind it?).
->match() does alias matching and ->setup(). If alias matching failed,
exact name match takes place. We don't call ->setup() for all consoles,
but only for those that have exact name match:
if (strcmp(c->name, newcon->name) != 0)
continue;
As to why we don't stop sooner in that loop - I need to to do some
archaeology. We need to have CON_CONSDEV at proper place, which is
IIRC the last matching console.
Pretty much every time we tried to change the logic we ended up
reverting the changes.
> In both cases we will get the console to have CON_ENABLED flag set.
And there are sneaky consoles that have CON_ENABLED before we even
register them.
-ss
Powered by blists - more mailing lists