Boot Consoles question...

Boot Consoles question...

[Robin Getz]

Quick question...

In register_console()

        if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == 
CON_CONSDEV)) {
		[[snip]]
                newcon->flags &= ~CON_PRINTBUFFER;
        }

So - when we are switching over from a boot console to a "real" console 
- we don't back up the console, and print everything out.

This means that the boot console is on a different device than that
"real" console - you don't actually see the full boot message (from 
log_start) on the "real" console.

Is this what is intended (that the boot message gets split into 2 -
1/3 going into the bootconsole - and the remaining to to the real 
console?)

I can understand this when both (boot and real) are the same device (serial) 
or vga, but where they are not - it is a little confusing to the user - isn't 
it?

Thanks
-Robin

Re: Boot Consoles question...

[Ingo Molnar]

* Robin Getz <rgetz@blackfin.uclinux.org> wrote:

> Quick question...
> 
> In register_console()
> 
>         if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == 
> CON_CONSDEV)) {
> 		[[snip]]
>                 newcon->flags &= ~CON_PRINTBUFFER;
>         }
> 
> So - when we are switching over from a boot console to a "real" 
> console - we don't back up the console, and print everything out.
> 
> This means that the boot console is on a different device than 
> that "real" console - you don't actually see the full boot message 
> (from log_start) on the "real" console.
> 
> Is this what is intended (that the boot message gets split into 2 
> - 1/3 going into the bootconsole - and the remaining to to the 
> real console?)
> 
> I can understand this when both (boot and real) are the same 
> device (serial) or vga, but where they are not - it is a little 
> confusing to the user - isn't it?

Could be changed i guess ... but is it really an issue? All messages 
should be in the syslog buffer (if it's large enough). One artifact 
could be manual scroll-back - it would perhaps be nice indeed to 
allow the scrollback to the top of the bootlog.

	Ingo

Re: Boot Consoles question...

[Robin Getz]

On Sat 4 Jul 2009 06:29, Ingo Molnar pondered:
> Could be changed i guess ... but is it really an issue?

It is just a change from "normal" (when the kernel has no boot console).

We were looking at shipping our default kernel, with a boot console that wrote 
to a fixed place in memory - If something got hosed before the "real" console 
was registered, the bootloader would print it out on the next boot...

No more people complaining about the kernel crashing or hanging without any 
output on the console. (which happens more often than you would like with 
people doing weird things to their kernel during embedded development).

The down side - is the above - the info before the "real" console starts does 
not come out the real console...

> All messages 
>  should be in the syslog buffer (if it's large enough).

Yes. it does - but it still changes the "normal" boot look & feel...

>  One artifact 
>  could be manual scroll-back - it would perhaps be nice indeed to
>  allow the scrollback to the top of the bootlog.

Exactly.

One of my thoughts (was since CON_PRINTBUFFER isn't used after 
register_console()) - was for the CON_BOOT's CON_PRINTBUFFER flag to control 
the clearing of the CON_PRINTBUFFER for the real console or not...

All early_printk consoles that I looked at have their CON_PRINTBUFFER set.

Which means that something like should do the trick -- allow people who want 
to override things to do so, and still have the today's setup work as is...

--- kernel/printk.c     (revision 6920)
+++ kernel/printk.c     (working copy)
@@ -1144,7 +1144,7 @@
@@ -1230,12 +1230,16 @@
                 * everything out, before we unregister the console(s)
                 */
                printk(KERN_INFO "console handover:");
-               for_each_console(bcon)
+               flags = 0;
+               for_each_console(bcon) {
                        printk("boot [%s%d] ", bcon->name, bcon->index);
+                       flags |= bcon->flags & CON_PRINTBUFFER;
+               }
                printk(" -> real [%s%d]\n", newcon->name, newcon->index);
                for_each_console(bcon)
                        unregister_console(bcon);
-               newcon->flags &= ~CON_PRINTBUFFER;
+               if (flags)
+                       newcon->flags &= ~CON_PRINTBUFFER;
        } else {
                printk(KERN_INFO "%sconsole [%s%d] enabled\n",
                        (newcon->flags & CON_BOOT) ? "boot" : "" ,

And then in my early_printk console_enable:

        register_console(&early_shadow_console);
        /* Make sure that the real console prints from the beginning */
        early_shadow_console->flags &= ~CON_PRINTBUFFER;

?

Thoughts?

Re: Boot Consoles question...

[Robin Getz]

On Sat 4 Jul 2009 12:07, Robin Getz pondered:
> On Sat 4 Jul 2009 06:29, Ingo Molnar pondered:
> > Could be changed i guess ... but is it really an issue?
> 
> It is just a change from "normal" (when the kernel has no boot console).
> 
> >  One artifact 
> >  could be manual scroll-back - it would perhaps be nice indeed to
> >  allow the scrollback to the top of the bootlog.
> 
> Exactly.
> 
> One of my thoughts (was since CON_PRINTBUFFER isn't used after 
> register_console()) - was for the CON_BOOT's CON_PRINTBUFFER flag to control 
> the clearing of the CON_PRINTBUFFER for the real console or not...
> 
> All early_printk consoles that I looked at have their CON_PRINTBUFFER set.
> 
> Which means that something like should do the trick -- allow people who want 
> to override things to do so, and still have the today's setup work as is...

I guess no one liked that idea?

How about at least making sure that the real console gets a message that
something is on the bootconsole? Right now the switch message:

console handover:boot [early_shadow0]  -> real [ttyBF0]

only is printed on the bootconsole, not on the real console - so someone 
looking at the real console may not know there is anything on the boot 
console. They just think that things are missing...

-Robin

Re: Boot Consoles question...

[Ingo Molnar]

* Robin Getz <rgetz@blackfin.uclinux.org> wrote:

> On Sat 4 Jul 2009 12:07, Robin Getz pondered:
> > On Sat 4 Jul 2009 06:29, Ingo Molnar pondered:
> > > Could be changed i guess ... but is it really an issue?
> > 
> > It is just a change from "normal" (when the kernel has no boot console).
> > 
> > >  One artifact 
> > >  could be manual scroll-back - it would perhaps be nice indeed to
> > >  allow the scrollback to the top of the bootlog.
> > 
> > Exactly.
> > 
> > One of my thoughts (was since CON_PRINTBUFFER isn't used after 
> > register_console()) - was for the CON_BOOT's CON_PRINTBUFFER flag to control 
> > the clearing of the CON_PRINTBUFFER for the real console or not...
> > 
> > All early_printk consoles that I looked at have their CON_PRINTBUFFER set.
> > 
> > Which means that something like should do the trick -- allow people who want 
> > to override things to do so, and still have the today's setup work as is...
> 
> I guess no one liked that idea?

No, this means no-one objected :)

> How about at least making sure that the real console gets a 
> message that something is on the bootconsole? Right now the switch 
> message:
> 
> console handover:boot [early_shadow0]  -> real [ttyBF0]
> 
> only is printed on the bootconsole, not on the real console - so 
> someone looking at the real console may not know there is anything 
> on the boot console. They just think that things are missing...

Mind sending a full (changelogged, titled, etc.) patch for the other 
bit as well? It kind of overlaps this one but both make sense, 
especially if people end up objecting against the more intrusive one 
and it gets dropped/reverted ;-)

	Ingo

Re: Boot Consoles question...

[Robin Getz]

On Fri 10 Jul 2009 06:28, Ingo Molnar pondered:
> 
> * Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> 
> > On Sat 4 Jul 2009 12:07, Robin Getz pondered:
> > > On Sat 4 Jul 2009 06:29, Ingo Molnar pondered:
> > > > Could be changed i guess ... but is it really an issue?
> > > 
> > > It is just a change from "normal" (when the kernel has no boot
> > > console).
> > > 
> > > >  One artifact 
> > > >  could be manual scroll-back - it would perhaps be nice indeed to
> > > >  allow the scrollback to the top of the bootlog.
> > > 
> > > Exactly.
> > > 
> > > One of my thoughts (was since CON_PRINTBUFFER isn't used after 
> > > register_console()) - was for the CON_BOOT's CON_PRINTBUFFER flag to
> > > control the clearing of the CON_PRINTBUFFER for the real console or
> > > not... 
> > > 
> > > All early_printk consoles that I looked at have their
> > > CON_PRINTBUFFER set.
> > > 
> > > Which means that something like should do the trick -- allow people
> > > who want 
> > > to override things to do so, and still have the today's setup work
> > > as is...
> > 
> > I guess no one liked that idea?
> 
> No, this means no-one objected :)

Silence is consensus?

> > How about at least making sure that the real console gets a 
> > message that something is on the bootconsole? Right now the switch 
> > message:
> > 
> > console handover:boot [early_shadow0]  -> real [ttyBF0]
> > 
> > only is printed on the bootconsole, not on the real console - so 
> > someone looking at the real console may not know there is anything 
> > on the boot console. They just think that things are missing...
> 
> Mind sending a full (changelogged, titled, etc.) patch for the other 
> bit as well? It kind of overlaps this one but both make sense, 
> especially if people end up objecting against the more intrusive one 
> and it gets dropped/reverted ;-)

Will do - (as soon as I get my system up and running again - moved buildings, 
so still unpacking)...

Re: Boot Consoles question...

[Ingo Molnar]

* Robin Getz <rgetz@blackfin.uclinux.org> wrote:

> On Fri 10 Jul 2009 06:28, Ingo Molnar pondered:
> > 
> > * Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> > 
> > > On Sat 4 Jul 2009 12:07, Robin Getz pondered:
> > > > On Sat 4 Jul 2009 06:29, Ingo Molnar pondered:
> > > > > Could be changed i guess ... but is it really an issue?
> > > > 
> > > > It is just a change from "normal" (when the kernel has no boot
> > > > console).
> > > > 
> > > > >  One artifact 
> > > > >  could be manual scroll-back - it would perhaps be nice indeed to
> > > > >  allow the scrollback to the top of the bootlog.
> > > > 
> > > > Exactly.
> > > > 
> > > > One of my thoughts (was since CON_PRINTBUFFER isn't used after 
> > > > register_console()) - was for the CON_BOOT's CON_PRINTBUFFER flag to
> > > > control the clearing of the CON_PRINTBUFFER for the real console or
> > > > not... 
> > > > 
> > > > All early_printk consoles that I looked at have their
> > > > CON_PRINTBUFFER set.
> > > > 
> > > > Which means that something like should do the trick -- allow people
> > > > who want 
> > > > to override things to do so, and still have the today's setup work
> > > > as is...
> > > 
> > > I guess no one liked that idea?
> > 
> > No, this means no-one objected :)
> 
> Silence is consensus?

No - silence is 'no objections expressed'. That doesnt make a change 
agreed on, it makes a change "not objected to so far" ;-) It could 
still be wrong, the onus is on you and me to make sure that isnt the 
case.

	Ingo

[PATCH] kernel.printk.c - ensure that "console enabled" messages are printed on the console

[Robin Getz]

From: Robin Getz <rgetz@blackfin.uclinux.org>

Today, when a console is registered without CON_PRINTBUFFER, end users never
see the announcement of it being added, and never know if they missed something,
if the console is really at the start or not, and just leads to general confusion.

This re-orders existing code, to make sure the console is added, before 
the "console [%s%d] enabled" is printed out - ensuring that this message
is _always_ seen.

This has the desired/intended side effect of making sure that 
"console enabled:" messages are printed on the bootconsole, and the real
console. This does cause the same line is printed twice if the bootconsole
and real console are the same device, but if they are on different devices,
the message is printed to both consoles.

Signed-off-by : Robin Getz <rgetz@blackfin.uclinux.org>

---

 printk.c |   44 +++++++++++++++++++++++++++++---------------
 1 file changed, 29 insertions(+), 15 deletions(-)

patch generated for -tip

---

diff --git a/kernel/printk.c b/kernel/printk.c
index 41fe609..60f35b9 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1240,22 +1240,14 @@ void register_console(struct console *newcon)
 	if (!(newcon->flags & CON_ENABLED))
 		return;
 
-	if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV)) {
-		/* we need to iterate through twice, to make sure we print
-		 * everything out, before we unregister the console(s)
-		 */
-		printk(KERN_INFO "console handover:");
-		for_each_console(bcon)
-			printk("boot [%s%d] ", bcon->name, bcon->index);
-		printk(" -> real [%s%d]\n", newcon->name, newcon->index);
-		for_each_console(bcon)
-			unregister_console(bcon);
+	/*
+	 * If we have a bootconsole, and are switching to a real console,
+	 * don't print everything out again, since when the boot console, and
+	 * the real console are the same physical device, it's annoying to
+	 * see the beginning boot messages twice
+	 */
+	if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV))
 		newcon->flags &= ~CON_PRINTBUFFER;
-	} else {
-		printk(KERN_INFO "%sconsole [%s%d] enabled\n",
-			(newcon->flags & CON_BOOT) ? "boot" : "" ,
-			newcon->name, newcon->index);
-	}
 
 	/*
 	 *	Put this console in the list - keep the
@@ -1281,6 +1273,28 @@ void register_console(struct console *newcon)
 		spin_unlock_irqrestore(&logbuf_lock, flags);
 	}
 	release_console_sem();
+
+	/*
+	 *  By unregistering the bootconsoles after we enable the real console
+	 * we get the "console xxx enabled" message on all the consoles - 
+	 * boot consoles, real consoles, etc - this is to ensure that end
+	 * users know there might be something in the kernel's log buffer that
+	 * went to the bootconsole (that they do not see on the real console)
+	 */
+	if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV)) {
+		/* we need to iterate through twice, to make sure we print
+		 * everything out, before we unregister the console(s)
+		 */
+		printk(KERN_INFO "console [%s%d] enabled, bootconsole disabled\n",
+			newcon->name, newcon->index);
+		for_each_console(bcon)
+			if (bcon->flags & CON_BOOT)
+				unregister_console(bcon);
+	} else {
+		printk(KERN_INFO "%sconsole [%s%d] enabled\n",
+			(newcon->flags & CON_BOOT) ? "boot" : "" ,
+			newcon->name, newcon->index);
+	}
 }
 EXPORT_SYMBOL(register_console);
 

Re: [PATCH] kernel.printk.c - ensure that "console enabled" messages are printed on the console

[Ingo Molnar]

* Robin Getz <rgetz@blackfin.uclinux.org> wrote:

> From: Robin Getz <rgetz@blackfin.uclinux.org>
> 
> Today, when a console is registered without CON_PRINTBUFFER, end 
> users never see the announcement of it being added, and never know 
> if they missed something, if the console is really at the start or 
> not, and just leads to general confusion.
> 
> This re-orders existing code, to make sure the console is added, 
> before the "console [%s%d] enabled" is printed out - ensuring that 
> this message is _always_ seen.
> 
> This has the desired/intended side effect of making sure that 
> "console enabled:" messages are printed on the bootconsole, and 
> the real console. This does cause the same line is printed twice 
> if the bootconsole and real console are the same device, but if 
> they are on different devices, the message is printed to both 
> consoles.
> 
> Signed-off-by : Robin Getz <rgetz@blackfin.uclinux.org>
> 
> ---
> 
>  printk.c |   44 +++++++++++++++++++++++++++++---------------
>  1 file changed, 29 insertions(+), 15 deletions(-)
> 
> patch generated for -tip

Looks good, applied it to tip:core/printk for v2.6.32, thanks Robin. 

i fixed a couple of small details in the patch:

 - re-broke the commit log as it was too wide for nice git log 
   output

 - fixed a stray whitespace warned about by scripts/checkpatch.pl

 - fixed another stray whitespace found the old fashioned way

 - fixed the patch title to match the prefix used by your previous 
   commit as well

	Ingo

Re: [PATCH] kernel.printk.c - ensure that "console enabled"messages are printed on the console

[Robin Getz]

On Fri 10 Jul 2009 06:25, Ingo Molnar pondered:
> 
> * Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> 
> > From: Robin Getz <rgetz@blackfin.uclinux.org>
> > 
> > Today, when a console is registered without CON_PRINTBUFFER, end 
> > users never see the announcement of it being added, and never know 
> > if they missed something, if the console is really at the start or 
> > not, and just leads to general confusion.
> > 
> > This re-orders existing code, to make sure the console is added, 
> > before the "console [%s%d] enabled" is printed out - ensuring that 
> > this message is _always_ seen.
> > 
> > This has the desired/intended side effect of making sure that 
> > "console enabled:" messages are printed on the bootconsole, and 
> > the real console. This does cause the same line is printed twice 
> > if the bootconsole and real console are the same device, but if 
> > they are on different devices, the message is printed to both 
> > consoles.
> > 
> > Signed-off-by : Robin Getz <rgetz@blackfin.uclinux.org>
> > 
> > ---
> > 
> >  printk.c |   44 +++++++++++++++++++++++++++++---------------
> >  1 file changed, 29 insertions(+), 15 deletions(-)
> > 
> > patch generated for -tip
> 
> Looks good, applied it to tip:core/printk for v2.6.32, thanks Robin. 
> 
> i fixed a couple of small details in the patch:
> 
>  - re-broke the commit log as it was too wide for nice git log 
>    output

Hmm - I didn't know there was a restriction on this - what is the number?

>  - fixed a stray whitespace warned about by scripts/checkpatch.pl
>  - fixed another stray whitespace found the old fashioned way
>  - fixed the patch title to match the prefix used by your previous 
>    commit as well

Thanks
-Robin

Re: [PATCH] kernel.printk.c - ensure that "console enabled"messages are printed on the console

[Ingo Molnar]

* Robin Getz <rgetz@blackfin.uclinux.org> wrote:

> On Fri 10 Jul 2009 06:25, Ingo Molnar pondered:
> > 
> > * Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> > 
> > > From: Robin Getz <rgetz@blackfin.uclinux.org>
> > > 
> > > Today, when a console is registered without CON_PRINTBUFFER, end 
> > > users never see the announcement of it being added, and never know 
> > > if they missed something, if the console is really at the start or 
> > > not, and just leads to general confusion.
> > > 
> > > This re-orders existing code, to make sure the console is added, 
> > > before the "console [%s%d] enabled" is printed out - ensuring that 
> > > this message is _always_ seen.
> > > 
> > > This has the desired/intended side effect of making sure that 
> > > "console enabled:" messages are printed on the bootconsole, and 
> > > the real console. This does cause the same line is printed twice 
> > > if the bootconsole and real console are the same device, but if 
> > > they are on different devices, the message is printed to both 
> > > consoles.
> > > 
> > > Signed-off-by : Robin Getz <rgetz@blackfin.uclinux.org>
> > > 
> > > ---
> > > 
> > >  printk.c |   44 +++++++++++++++++++++++++++++---------------
> > >  1 file changed, 29 insertions(+), 15 deletions(-)
> > > 
> > > patch generated for -tip
> > 
> > Looks good, applied it to tip:core/printk for v2.6.32, thanks Robin. 
> > 
> > i fixed a couple of small details in the patch:
> > 
> >  - re-broke the commit log as it was too wide for nice git log 
> >    output
> 
> Hmm - I didn't know there was a restriction on this - what is the number?

I use:

autocmd BufNewFile,BufRead *.patch setlocal textwidth=60

in ~/.vimrc - i.e. 60 cols.

'git log' adds 4 leading spaces to commit messages and then if you 
look at it via a small terminal it can quickly wrap at the end, 
making the commit log harder to read.

Also, commit logs get quoted in emails and if we reply to that in up 
to a depth of 4, the colums do get eaten up quickly.

60 cols sounds like a reasonable compromise. There's no 'written' 
rule for this AFAIK, i just do it for all changes i commit, to 
increase commit quality.

	Ingo

Re: [PATCH] kernel.printk.c - ensure that "console enabled"messages are printed on the console

[Mike Frysinger]

On Fri, Jul 10, 2009 at 10:16, Ingo Molnar wrote:
> * Robin Getz wrote:
>> On Fri 10 Jul 2009 06:25, Ingo Molnar pondered:
>> >  - re-broke the commit log as it was too wide for nice git log
>> >    output
>>
>> Hmm - I didn't know there was a restriction on this - what is the number?
>
> 'git log' adds 4 leading spaces to commit messages and then if you
> look at it via a small terminal it can quickly wrap at the end,
> making the commit log harder to read.
>
> Also, commit logs get quoted in emails and if we reply to that in up
> to a depth of 4, the colums do get eaten up quickly.
>
> 60 cols sounds like a reasonable compromise. There's no 'written'
> rule for this AFAIK, i just do it for all changes i commit, to
> increase commit quality.

the upper rule based on what you point out:
 - git-log adds 4 and 80 cols is the min directly supported
 - logs go through e-mail which wraps at 78
leaves us with user-typed paragraphs at 76

for copy & pasted output (i.e. gcc output and kernel crash logs), i
welsh on that a bit as it leaves it up to the viewer to wrap like
normal.
-mike

Re: [PATCH] kernel.printk.c - ensure that "console enabled" messages are printed on the console

[Andrew Morton]

On Fri, 10 Jul 2009 12:25:47 +0200
Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> 
> > From: Robin Getz <rgetz@blackfin.uclinux.org>
> > 
> > Today, when a console is registered without CON_PRINTBUFFER, end 
> > users never see the announcement of it being added, and never know 
> > if they missed something, if the console is really at the start or 
> > not, and just leads to general confusion.
> > 
> > This re-orders existing code, to make sure the console is added, 
> > before the "console [%s%d] enabled" is printed out - ensuring that 
> > this message is _always_ seen.
> > 
> > This has the desired/intended side effect of making sure that 
> > "console enabled:" messages are printed on the bootconsole, and 
> > the real console. This does cause the same line is printed twice 
> > if the bootconsole and real console are the same device, but if 
> > they are on different devices, the message is printed to both 
> > consoles.
> > 
> > Signed-off-by : Robin Getz <rgetz@blackfin.uclinux.org>
> > 
> > ---
> > 
> >  printk.c |   44 +++++++++++++++++++++++++++++---------------
> >  1 file changed, 29 insertions(+), 15 deletions(-)
> > 
> > patch generated for -tip
> 
> Looks good, applied it to tip:core/printk for v2.6.32, thanks Robin. 
> 

Seven days later, this isn't in linux-next.  Did it get lost?

Re: [PATCH] kernel.printk.c - ensure that "console enabled" messages are printed on the console

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

Hi Andrew,

On Fri, 17 Jul 2009 17:48:52 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 10 Jul 2009 12:25:47 +0200
> Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> > 
> > > From: Robin Getz <rgetz@blackfin.uclinux.org>
> > > 
> > > Today, when a console is registered without CON_PRINTBUFFER, end 
> > 
> > Looks good, applied it to tip:core/printk for v2.6.32, thanks Robin. 
> 
> Seven days later, this isn't in linux-next.  Did it get lost?

It went into tip:core/printk on July 10.  It has not propagated to
tip:auto-latest (which is what is merged int linux-next) yet.  The last
update of auto-latest was about July 6.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

[tip:core/printk] printk: Ensure that "console enabled" messages are printed on the console

[tip-bot for Robin Getz]

Commit-ID:  8259cf4342029aad37660e524178c8858f48b0ab
Gitweb:     http://git.kernel.org/tip/8259cf4342029aad37660e524178c8858f48b0ab
Author:     Robin Getz <rgetz@blackfin.uclinux.org>
AuthorDate: Thu, 9 Jul 2009 13:08:37 -0400
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 10 Jul 2009 12:24:47 +0200

printk: Ensure that "console enabled" messages are printed on the console

Today, when a console is registered without CON_PRINTBUFFER,
end users never see the announcement of it being added, and
never know if they missed something, if the console is really
at the start or not, and just leads to general confusion.

This re-orders existing code, to make sure the console is
added, before the "console [%s%d] enabled" is printed out -
ensuring that this message is _always_ seen.

This has the desired/intended side effect of making sure that
"console enabled:" messages are printed on the bootconsole, and
the real console. This does cause the same line is printed
twice if the bootconsole and real console are the same device,
but if they are on different devices, the message is printed to
both consoles.

Signed-off-by : Robin Getz <rgetz@blackfin.uclinux.org>
Cc: "Andrew Morton" <akpm@linux-foundation.org>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>
LKML-Reference: <200907091308.37370.rgetz@blackfin.uclinux.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>


---
 kernel/printk.c |   44 +++++++++++++++++++++++++++++---------------
 1 files changed, 29 insertions(+), 15 deletions(-)

diff --git a/kernel/printk.c b/kernel/printk.c
index 41fe609..668df35 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -1240,22 +1240,14 @@ void register_console(struct console *newcon)
 	if (!(newcon->flags & CON_ENABLED))
 		return;
 
-	if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV)) {
-		/* we need to iterate through twice, to make sure we print
-		 * everything out, before we unregister the console(s)
-		 */
-		printk(KERN_INFO "console handover:");
-		for_each_console(bcon)
-			printk("boot [%s%d] ", bcon->name, bcon->index);
-		printk(" -> real [%s%d]\n", newcon->name, newcon->index);
-		for_each_console(bcon)
-			unregister_console(bcon);
+	/*
+	 * If we have a bootconsole, and are switching to a real console,
+	 * don't print everything out again, since when the boot console, and
+	 * the real console are the same physical device, it's annoying to
+	 * see the beginning boot messages twice
+	 */
+	if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV))
 		newcon->flags &= ~CON_PRINTBUFFER;
-	} else {
-		printk(KERN_INFO "%sconsole [%s%d] enabled\n",
-			(newcon->flags & CON_BOOT) ? "boot" : "" ,
-			newcon->name, newcon->index);
-	}
 
 	/*
 	 *	Put this console in the list - keep the
@@ -1281,6 +1273,28 @@ void register_console(struct console *newcon)
 		spin_unlock_irqrestore(&logbuf_lock, flags);
 	}
 	release_console_sem();
+
+	/*
+	 * By unregistering the bootconsoles after we enable the real console
+	 * we get the "console xxx enabled" message on all the consoles -
+	 * boot consoles, real consoles, etc - this is to ensure that end
+	 * users know there might be something in the kernel's log buffer that
+	 * went to the bootconsole (that they do not see on the real console)
+	 */
+	if (bcon && ((newcon->flags & (CON_CONSDEV | CON_BOOT)) == CON_CONSDEV)) {
+		/* we need to iterate through twice, to make sure we print
+		 * everything out, before we unregister the console(s)
+		 */
+		printk(KERN_INFO "console [%s%d] enabled, bootconsole disabled\n",
+			newcon->name, newcon->index);
+		for_each_console(bcon)
+			if (bcon->flags & CON_BOOT)
+				unregister_console(bcon);
+	} else {
+		printk(KERN_INFO "%sconsole [%s%d] enabled\n",
+			(newcon->flags & CON_BOOT) ? "boot" : "" ,
+			newcon->name, newcon->index);
+	}
 }
 EXPORT_SYMBOL(register_console);