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
* Robin Getz <[email protected]> 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
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?
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
From: Robin Getz <[email protected]>
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 <[email protected]>
---
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);
* Robin Getz <[email protected]> wrote:
> From: Robin Getz <[email protected]>
>
> 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 <[email protected]>
>
> ---
>
> 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
* Robin Getz <[email protected]> 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
Commit-ID: 8259cf4342029aad37660e524178c8858f48b0ab
Gitweb: http://git.kernel.org/tip/8259cf4342029aad37660e524178c8858f48b0ab
Author: Robin Getz <[email protected]>
AuthorDate: Thu, 9 Jul 2009 13:08:37 -0400
Committer: Ingo Molnar <[email protected]>
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 <[email protected]>
Cc: "Andrew Morton" <[email protected]>
Cc: "Linus Torvalds" <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
---
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);
On Fri 10 Jul 2009 06:25, Ingo Molnar pondered:
>
> * Robin Getz <[email protected]> wrote:
>
> > From: Robin Getz <[email protected]>
> >
> > 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 <[email protected]>
> >
> > ---
> >
> > 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
* Robin Getz <[email protected]> wrote:
> On Fri 10 Jul 2009 06:25, Ingo Molnar pondered:
> >
> > * Robin Getz <[email protected]> wrote:
> >
> > > From: Robin Getz <[email protected]>
> > >
> > > 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 <[email protected]>
> > >
> > > ---
> > >
> > > 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
On Fri 10 Jul 2009 06:28, Ingo Molnar pondered:
>
> * Robin Getz <[email protected]> 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)...
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
* Robin Getz <[email protected]> wrote:
> On Fri 10 Jul 2009 06:28, Ingo Molnar pondered:
> >
> > * Robin Getz <[email protected]> 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
On Fri, 10 Jul 2009 12:25:47 +0200
Ingo Molnar <[email protected]> wrote:
>
> * Robin Getz <[email protected]> wrote:
>
> > From: Robin Getz <[email protected]>
> >
> > 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 <[email protected]>
> >
> > ---
> >
> > 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?
Hi Andrew,
On Fri, 17 Jul 2009 17:48:52 -0700 Andrew Morton <[email protected]> wrote:
>
> On Fri, 10 Jul 2009 12:25:47 +0200
> Ingo Molnar <[email protected]> wrote:
>
> >
> > * Robin Getz <[email protected]> wrote:
> >
> > > From: Robin Getz <[email protected]>
> > >
> > > 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 [email protected]
http://www.canb.auug.org.au/~sfr/