linux-kernel - Re: earlycon: no match?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 May 2015 21:14:54 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	Peter Hurley <peter@...leysoftware.com>
cc:	Robert Schwebel <r.schwebel@...gutronix.de>,
	linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel@...gutronix.de
Subject: Re: earlycon: no match?

On Thu, 7 May 2015, Peter Hurley wrote:

> >  What's the point of having two parameters as synonyms whose syntax is not 
> > compatible to each other in the general case?  I'd expect the following 
> > cases to be handled:
> > 
> > 1. Regular console only (no early console requested) => `console=foo...'.
> > 
> > 2. Both early and regular console => `earlycon=blah... console=foo...'.
> > 
> > 3. Early console handing over to regular console => `earlycon=blah...'.
> 
>   4. Early console only => `earlycon=blah...'
> 
> How to distinguish between 3 & 4?

 Good point.  If you want to disable the handover, then it has to be 
handled by the early console driver somehow.  Perhaps an option for 
`earlycon=' (e.g. `nohandover') would be required for that.  In that case 
the default selection would apply for the regular console, depending on 
the available drivers.

 Your concern appears to me unrelated to `earlycon=' vs `console=' 
parameter aliasing though.  The same observation about the handover 
applies whether the parameters are aliased to each other or not.  Have I 
missed anything?

> > Why do you want to support `console=blah...' too (a question to be asked 
> > back in 2007, but better late than never)?
> 
> Command line is considered to be userspace, so it doesn't really matter
> what I think about whether console= should have been overloaded like that.
> 
> The fact is, it was.

 The change has not been cast in stone, it can always be reverted if on 
the second thoughts it is concluded to have been wrong.

 How does this overload interact with multiple `console=' options being 
present BTW, which one is considered the early console?  Or do we support 
driving multiple early consoles in parallel just as we do with regular 
consoles?

> >  If you do need to support such aliasing, then I suggest that you complain 
> > about no early console match only if `earlycon=blah...' has been truly 
> > used and avoid the warning where `console=blah...' has been used instead 
> > (a warning about the latter can be issued where no regular console match 
> > happened).
> 
> I'm tearing it out;  I'd prefer to go back to the old way where you
> don't know why your earlycon didn't start, and I don't get emails
> complaining about logs.

 Up to you.

  Maciej
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/