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

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090710141618.GF26264@elte.hu>
Date:	Fri, 10 Jul 2009 16:16:18 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Robin Getz <rgetz@...ckfin.uclinux.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] kernel.printk.c - ensure that "console
	enabled"messages are printed on the console


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

> On Fri 10 Jul 2009 06:25, Ingo Molnar pondered:
> > 
> > * Robin Getz <rgetz@...ckfin.uclinux.org> wrote:
> > 
> > > From: Robin Getz <rgetz@...ckfin.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@...ckfin.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
--
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/