linux-kernel - Re: [PATCH] bitops: simplify generic bit finding functions

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]

Date:	Mon, 28 Apr 2008 12:37:59 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
cc:	Harvey Harrison <harvey.harrison@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>
Subject: Re: [PATCH] bitops: simplify generic bit finding functions

On Mon, 28 Apr 2008, Thomas Gleixner wrote:
> 
> I doubt that that is worth the trouble and we should just remove those
> inlines alltogether. This was discussed before, but Andi objected to
> remove those micro optimizations and nobody had time to actually
> verify the real benefits.

Thanks for checking.

In general, I think we should act the other way: we should *assume* that 
inlines and complex macros in header files are not worth it and we'd be 
better off with just plain function calls, unless it's really obvious that 
the inline function is always worth it.

We have tons of good examples of inline functions in headers that really 
*really* want to be that way: <linux/list.h> is generally a collection of 
things that clearly expand to somthing that is (a) easily critical and (b) 
inlining things generally really causes a smaller code footprint than 
having a "call" instruction and all the argument setup - regardless of how 
many times it is done.

So we do have cases where the inlines are obviously worth it. But in 
general, I think we should try to move things from the header files into 
*.c files unless there is a really clear reason for keeping it that way.

(Some inline functions do depend on things like constant arguments goign 
away, with kmalloc() being a good example of some really nasty header file 
tricks that are likely worth it despite their extreme ugliness)

		Linus
--
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/