linux-kernel - Re: [PATCH x86/mm] x86-64, NUMA: Fix distance table handling

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]

Message-ID: <20110302103631.GA25608@elte.hu>
Date:	Wed, 2 Mar 2011 11:36:31 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Tejun Heo <tj@...nel.org>
Cc:	David Rientjes <rientjes@...gle.com>,
	Yinghai Lu <yinghai@...nel.org>, tglx@...utronix.de,
	"H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH x86/mm] x86-64, NUMA: Fix distance table handling

* Tejun Heo <tj@...nel.org> wrote:

> FWIW, I'm not really decided about 80 vs. whatever column issue.

It only really matters when the underlying code structure is clearly inefficient: 
too many indentations, etc.

but printks or function calls that go beyond 80 cols a bit do not deserve to be 
line-broken.

> Having a common limit definitely helps a lot but it seems almost
> impossible to agree on one - is it 90, 95, 100 or 120?  Given that, it
> almost seems just sticking to 80 might be the only doable solution.

The problem is that many sensible code structures break with a limit of 80.

So i'd suggest being permissive when the code is fine (printks, function calls at 
the first or second level of indentation, etc.) and being conservative when the 
underlying code is not fine.

Thanks,

	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/