linux-kernel - Re: [2.6 patch] acpi/battery.c: make 2 functions static

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, 3 Mar 2008 12:45:34 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Adrian Bunk <bunk@...nel.org>
Cc:	Sam Ravnborg <sam@...nborg.org>,
	Alexey Starikovskiy <aystarik@...il.com>, lenb@...nel.org,
	astarikovskiy@...e.de, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [2.6 patch] acpi/battery.c: make 2 functions static

* Adrian Bunk <bunk@...nel.org> wrote:

> are the result of a quick Google search of me stating this previously on 
> linux-kernel. It might have been more often, but I'm too lame too 
> search further.
> 
> http://lkml.org/lkml/2007/1/19/36

that's a side-note, not a bugreport and not a patch to fix it.

> http://lkml.org/lkml/2007/4/9/363

this second one is this very thread that i replied to.

> > no, what we should nuke is this always_inline definition. That was 
> > always the intention of FORCED_INLINE, and the removal of 
> > FORCED_INLINE was to _remove the forcing_, not to make it 
> > unconditional.
> 
> It was always unconditional, and neither adding, toggling nor removing 
> of CONFIG_FORCED_INLINING changed this invariant.
> 
> And what we should do is to attack the excessive wrong usage of 
> inlines in .c files, not messing with a global #define in a way that 
> the results on 24 architectures with 7 different releases of gcc would 
> be unpredictable.

i see, so you never properly reported and fixed it because you prefer a 
1000 small crappy changes over one change. You could have significantly 
contributed to truly making Linux smaller, but you decided not to do it.

and i disagree with your notion that flipping it around is risky in any 
unacceptable or unmanageable way. It has far less risks on the compiler 
than say CONFIG_CC_OPTIMIZE_FOR_SIZE. It has far less risks than 
changing to a new compiler version. Why you think it's "unpredictable" 
is a mystery to me.

It almost seems to me you were happy with having that bug in the kernel? 
Please tell me that i'm wrong about that impression!

i'll reinstate this .config option and let it do the right thing. Forced 
inlining was supposed to be _phased out_, not phased in.

	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/