Message-ID: <49F26C38.9000301@redhat.com>
Date:	Fri, 24 Apr 2009 21:49:44 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Tim Abbott <tabbott@....EDU>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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>,
	"Theodore Ts'o" <tytso@....EDU>,
	Nikanth Karthikesan <knikanth@...e.de>,
	Arjan van de Ven <arjan@...radead.org>,
	Paul Mundt <lethal@...ux-sh.org>,
	Américo Wang <xiyou.wangcong@...il.com>,
	Ralf Baechle <ralf@...ux-mips.org>,
	Kyle McMaartin <kyle@...artin.ca>,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH v3 0/3] Add support for compiling with -ffunction-sections
 -fdata-sections

Tim Abbott wrote:
> On Fri, 24 Apr 2009, Masami Hiramatsu wrote:
> 
>> What would you think about posting these patches plus -ffunction-sections/
>> -fdata-sections patch to -mm tree, -tip tree, or -next tree as
>> "playable" Ksplice patchset?
> 
> The section rename patch often merge conflicts with other changes.  I 
> think that having it sit out in one of those trees for another release 
> would result in a lot of unnecessary work rebasing patches between that 
> tree and Linus' tree.

I think those are not unnecessary work, because those changes will also
be merged to linus tree in the future. Don't you think new feature
proposer should pay the cost for updating related works (or, obtaining
agreement of each developer for updating their patches)?


> Once these -ffunction-sections support patches are merged, I intend to 
> post the rest of the Ksplice patchset for one of those trees.

Of course, but doesn't it need to be merged into linus tree?


>> If there are actual problems on those arch, I think you'd better post
>> these patches as bugfixes with bug reports.
> 
> These problems are all discussed in the commit messages of the relevant 
> patches.
> 
> One patch fixes modposting a kernel with more than 65536 ELF sections.  
> It is certainly possible to get this many with allyesconfig and 
> -ffunction-sections -fdata-sections.

This will be reasonable bugfix for the arches which already use
-ffunction-sections -fdata-sections.

> Another fixes the issue that when you build with -ffunction-sections, 
> modpost will print a large number of spurious warnings when it sees 
> sections like .rodata.__func__.12345 which are generated by the __FUNC__ 
> macro.

Is that possible to change the patches to work if the kernel is compiled
with -ffunction-sections?
If so, no one will complain about those changes.

> The patch with many scattered changes fixes the problem that with 
> -ffunction-sections -fdata-sections, a function named head gets put in the 
> ".text.head" section, and your "static int percpu" ends up in the 
> ".data.percpu" section and probably ends up being made percpu.  This is a 
> potentially nasty problem.

For this patch, I agree with Sam Ravnborg.
I think his suggestion is a good idea.


Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

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