linux-serial.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	linux-serial@vger.kernel.org,
	Steven Rostedt <rostedt@goodmis.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] printk: Unconditionally unregister boot consoles if in init section
Date: Wed, 12 Jul 2017 13:11:17 +0200	[thread overview]
Message-ID: <20170712111117.GD3393@pathway.suse.cz> (raw)
In-Reply-To: <86ff1193-8485-4b14-492f-627720c1d868@imgtec.com>

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.

The remaining use in register_console() does not make much sense.
It keeps the boot console after the preferred real one was registered.


> My other patch, placing serial earlycon in the init section is then
> the wrong way round and we need to remove __init from e.g. early8250
> and so on.

Yup.

> >Matt, is there any chance that you look into this possibility?
> 
> Sure, I can look at fixing up console drivers which we use on the
> MIPS architecture.

I have discussed this with my colleagues. It seems that implementation
of keep_bootcon option is pretty broken. It allows to debug broken
system using unreliable consoles (already freed). Therefore enabling
the option adds more problems on its own.

It would be nice to fix it. But it looks rather complicated. There
are several possibilities that are more or less hacky. It is hard
to guess the best solution if we do not know who is using it, how
it helps or sucks for them.

Before we spend a lot of time on this. Let me first try to send an RFC
to remove the feature and put more people into CC. It will either
be accepted or we will get arguments that would justify the needed
changes to fix it.

Best Regards,
Petr


PS: If you already stared migrating some consoles from the init
section, I would be interested into feedback about what problems
you did meet so far.

  reply	other threads:[~2017-07-12 11:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 10:38 [PATCH 1/2] printk: Unconditionally unregister boot consoles if in init section Matt Redfearn
2017-07-06 10:38 ` [PATCH 2/2] serial: earlycon: Make early_con as __initdata Matt Redfearn
2017-07-07  4:47   ` Sergey Senozhatsky
2017-07-07  4:45 ` [PATCH 1/2] printk: Unconditionally unregister boot consoles if in init section Sergey Senozhatsky
2017-07-07  7:58   ` Matt Redfearn
2017-07-11 12:43     ` Petr Mladek
2017-07-11 14:41       ` Matt Redfearn
2017-07-12 11:11         ` Petr Mladek [this message]
2017-07-14 12:40           ` Petr Mladek
2017-07-14 13:58             ` Matt Redfearn
2017-07-14 21:54       ` Sergey Senozhatsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170712111117.GD3393@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=matt.redfearn@imgtec.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=sergey.senozhatsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).