[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170714124026.GA32632@pathway.suse.cz>
Date: Fri, 14 Jul 2017 14:40:26 +0200
From: Petr Mladek <pmladek@...e.com>
To: Matt Redfearn <matt.redfearn@...tec.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jslaby@...e.com>, linux-serial@...r.kernel.org,
Steven Rostedt <rostedt@...dmis.org>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] printk: Unconditionally unregister boot consoles if
in init section
On Wed 2017-07-12 13:11:17, Petr Mladek wrote:
> On Tue 2017-07-11 15:41:50, Matt Redfearn wrote:
> > On 11/07/17 13:43, Petr Mladek wrote:
> > >IMHO, the reasonable solution is to move early console code and data
> > >out of the init sections. We should do this for the early consoles
> > >where the corresponding real console is registered using a deferred
> > >probe. Others should be already replaced by the real console when
> > >printk_late_init() is called. At least this is how I understand it.
> >
> > This seems like the most reasonable way forward to me as well,
> > though sadly will lead to some post-init kernel bloat.
> >
> > I still think, however, that this patch is a reasonable change to
> > make.
>
> The thing is that this patch "silently" makes the keep_bootcon
> option almost unusable.
I was wrong here. I thought that most early consoles used the init
section. It was mentioned somewhere and I looked a wrong way.
But this is not true. In fact, it seems that there are
only few of them. Most early consoles have struct console
and the write() callback in the normal section that is preserved.
Matt's patch and the keep_bootcon option makes sense to me
after all. Let me to resend Matt's patch with some small
improvements and one more patch that improves the check
of early consoles that use init section. I'll keep Matt
as the author of the first patch.
Best Regards,
Petr
Powered by blists - more mailing lists