Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755097AbZD1Ttb (ORCPT ); Tue, 28 Apr 2009 15:49:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752347AbZD1TtW (ORCPT ); Tue, 28 Apr 2009 15:49:22 -0400 Received: from BISCAYNE-ONE-STATION.MIT.EDU ([18.7.7.80]:53008 "EHLO biscayne-one-station.mit.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752037AbZD1TtV (ORCPT ); Tue, 28 Apr 2009 15:49:21 -0400 Date: Tue, 28 Apr 2009 15:48:24 -0400 (EDT) From: Tim Abbott To: Sam Ravnborg cc: Linus Torvalds , Linux kernel mailing list , Anders Kaseorg , Waseem Daher , Denys Vlasenko , Jeff Arnold , Paul Mundt , David Howells Subject: Re: [PATCH v2 00/15] clean up page aligned data and bss sections In-Reply-To: <1240938062-3264-1-git-send-email-tabbott@mit.edu> Message-ID: References: <1240938062-3264-1-git-send-email-tabbott@mit.edu> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Flag: NO X-Spam-Score: 0.00 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1749 Lines: 42 On Tue, 28 Apr 2009, Tim Abbott wrote: > Here's a new version of the page-aligned section cleanup patch > series. Changes since last version include: Sam, I am close to having prepared another 4 patch series of similar size to this one for .data.nosave, .data.cacheline_aligned, .data.init_task, and .data.read_mostly. Along with this page-aligned series and the things that have already been merged, I think these are all of the major cross-architecture patchsets needed for -ffunction-sections (there will remain a good number of section names that only appear on one or two architectures). It seems with this set of patches that we're going to bother all the arch maintainers several times if we handle these all completely independently (especially since each patch series has patches that depend on patches from the previous one). So, I was thinking perhaps we should proceed as follows: (1) I send a patch series that does the architecture-independent macro additions as well as the changes for one architecture (say, x86) to use those macros so that they can be reviewed along with the actual usage. (2) We get those reviewed and merge at least the architecture-independent patches (3) I can send one patch series for each architecture that is just using the macros that have already been merged; then the patch series are nicely decoupled and each arch maintainer only has to ack a single set of changes to their architecture. Does this plan make sense? -Tim Abbott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/