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

[Ingo Molnar <mingo@elte.hu>]

* 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