linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: Bastian Blank <waldi@debian.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.cz>,
	linuxppc-dev@lists.ozlabs.org,
	Debian kernel maintainers <debian-kernel@lists.debian.org>
Subject: Re: [PATCH] hvc_vio: Do not override preferred console set by kernel parameter
Date: Mon, 02 Sep 2013 09:55:40 +1000	[thread overview]
Message-ID: <1378079740.3978.13.camel@pasglop> (raw)
In-Reply-To: <1378052656.25743.33.camel@deadeye.wl.decadent.org.uk>

On Sun, 2013-09-01 at 17:24 +0100, Ben Hutchings wrote:
> The original version of this was done by Bastian Blank, who wrote:
> 
> > The problem is the following:
> > - Architecture specific code sets preferred console to something bogus.
> > - Command line handling tries to set preferred console but is overruled
> >   by the old setting.
> > 
> > The udbg0 console is a boot console and independant.
> 
> References: http://bugs.debian.org/492703
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> ---
> We've been carrying this in Debian for 5 years now, so it's about time
> it got reviewed.
> 
> I'm not convinced strstr() is the right way to check the command line
> (what if there's also a 'netconsole='?).

Also I think the problem should be solved elsewhere :-)

In the end, what that code is trying to do (as are all the other similar
instances) is to set "this is a good default in case nothing is
specified *or* what is specified doesn't actually exist".

Of course "doesn't exist" is tricky since the console could be provided
by a module loaded god knows when ... but in that case, maybe it does
make sense to stick to one of the known good defaults. After all, init
will fail without a tty ...

So I'm thinking we should in kernel/printk.c keep track of all those
"arch defaults" when console= is specified as "latent" consoles, and
right before starting init, if the specified one didn't work out (we
have no console with an associated tty), then go through those latent
ones and pick one that works.

Cheers,
Ben.

  reply	other threads:[~2013-09-01 23:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-01 16:24 [PATCH] hvc_vio: Do not override preferred console set by kernel parameter Ben Hutchings
2013-09-01 23:55 ` Benjamin Herrenschmidt [this message]
2013-09-26 21:22   ` Greg Kroah-Hartman
2013-09-26 22:00     ` Benjamin Herrenschmidt

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=1378079740.3978.13.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=ben@decadent.org.uk \
    --cc=debian-kernel@lists.debian.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=waldi@debian.org \
    /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).