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, 20 Apr 2009 17:35:32 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Tim Abbott <tabbott@....EDU>
cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>,
	Anders Kaseorg <andersk@....EDU>,
	Waseem Daher <wdaher@....EDU>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Jeff Arnold <jbarnold@....EDU>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jon Masters <jonathan@...masters.org>
Subject: Re: [PATCH v2 0/4] Add support for compiling with -ffunction-sections
 -fdata-sections



On Mon, 20 Apr 2009, Tim Abbott wrote:
> 
> I assume you're only worried about toolchain problems for people who are 
> actually using the -ffunction-sections option.  Would it help if the 
> -ffunction-sections compilation option were marked as experimental until 
> proven otherwise?

The thing is, people will enable them, and then maybe the compiler 
_appears_ to work, and things don't boot, and people spend tons of time 
chasing down somethign that just turns out to be a tools issue and not a 
kernel issue at all. And nobody happens to realize that what's up is that 
the person who reported the regression had enabled an experimental 
feature.

> If you're not willing to merge even an experimental option for 
> -ffunction-sections, would you at least be willing to merge the first 
> three patches in the patch series?  Compiling with -ffunction-sections 
> would not be supported by the mainline kernel, so any toolchain issues 
> with it would not be your problem.  But any vendor that wants to take 
> advantage of -ffunction-sections would still be able to use it without 
> having to maintain 300 lines of scattered changes to the kernel.

Are there any advantages outside of the size things?

Do we end up packing data better? 

I'd like to have some more champions of this code, in other words.

I'd be ok with merging it, but I haven't really gotten a strong feeling 
that anybody is going to enable it or use it.

			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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ