linux-kernel - Re: [patch] SLQB slab allocator

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]

Date:	Fri, 23 Jan 2009 13:56:49 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Nick Piggin <npiggin@...e.de>
Cc:	Pekka Enberg <penberg@...helsinki.fi>,
	Linux Memory Management List <linux-mm@...ck.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Lin Ming <ming.m.lin@...el.com>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Christoph Lameter <clameter@...r.sgi.com>
Subject: Re: [patch] SLQB slab allocator


* Nick Piggin <npiggin@...e.de> wrote:

> On Wed, Jan 21, 2009 at 06:40:10PM +0100, Ingo Molnar wrote:
> > -static inline void slqb_stat_inc(struct kmem_cache_list *list,
> > -				enum stat_item si)
> > +static inline void
> > +slqb_stat_inc(struct kmem_cache_list *list, enum stat_item si)
> >  {
> 
> Hmm, I'm not entirely fond of this style. [...]

well, it's a borderline situation and a nuance, and i think we agree on 
the two (much more common) boundary conditions:

 1) line fits into 80 cols - in that case we keep it all on a single line
    (this is the ideal case)

 2) line does not fit on two lines either - in that case we do the style
    that you used above.

On the boundary there's a special case though, and i tend to prefer:

 +static inline void
 +slqb_stat_inc(struct kmem_cache_list *list, enum stat_item si)

over:

 -static inline void slqb_stat_inc(struct kmem_cache_list *list,
 -				enum stat_item si)

for two reasons:

 1) the line break is not just arbitrarily in the middle of the 
    enumeration of arguments - it is right after function return type.

 2) the arguments fit on a single line - and often one wants to know that 
    signature. (return values are usually a separate thought)

 3) the return type stands out much better.

But again ... this is a nuance.

> [...] The former scales to longer lines with just a single style change 
> (putting args into new lines), wheras the latter first moves its 
> prefixes to a newline, then moves args as the line grows even longer.

the moment this 'boundary style' "overflows", it falls back to the 'lots 
of lines' case, where we generally put the function return type and the 
function name on the first line.

> I guess it is a matter of taste, not wrong either way... but I think 
> most of the mm code I'm used to looking at uses the former. Do you feel 
> strongly?

there are a handful of cases where the return type (and the function 
attributes) are _really_ long - in this case it really helps to have them 
decoupled from the arguments.

	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/