Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964970AbVI0PZv (ORCPT ); Tue, 27 Sep 2005 11:25:51 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S964972AbVI0PZv (ORCPT ); Tue, 27 Sep 2005 11:25:51 -0400 Received: from scrub.xs4all.nl ([194.109.195.176]:1758 "EHLO scrub.xs4all.nl") by vger.kernel.org with ESMTP id S964970AbVI0PZu (ORCPT ); Tue, 27 Sep 2005 11:25:50 -0400 Date: Tue, 27 Sep 2005 17:25:41 +0200 (CEST) From: Roman Zippel X-X-Sender: roman@scrub.home To: Herbert Poetzl cc: Andrew Morton , Linux Kernel ML Subject: Re: [Patch] eliminate CLONE_* duplications In-Reply-To: <20050921235810.GC18040@MAIL.13thfloor.at> Message-ID: References: <20050921092132.GA4710@MAIL.13thfloor.at> <20050921143954.GA10137@MAIL.13thfloor.at> <20050921151124.GB10137@MAIL.13thfloor.at> <20050921235810.GC18040@MAIL.13thfloor.at> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2567 Lines: 60 Hi, (Sorry for the delay.) On Thu, 22 Sep 2005, Herbert Poetzl wrote: > _what_ do you consider 'logically organized' because > putting all the CLONE_* stuff into a separate file is > pretty logical for me ... but obviously not for you. "logically organized" mainly means reducing dependencies by organizing them by their logical dependencies. If a large header file is included by a lot of other files, some parts maybe separated to reduce header dependencies. The same can be done for config dependencies, so that a config change doesn't necessarily recompiles the whole kernel. Your change doesn't reduce any dependecies and it's not such a big cleanup: arch/alpha/kernel/asm-offsets.c | 2 -- arch/alpha/kernel/entry.S | 1 + arch/cris/arch-v10/kernel/asm-offsets.c | 3 --- arch/cris/arch-v10/kernel/entry.S | 1 + arch/cris/arch-v32/kernel/asm-offsets.c | 3 --- arch/frv/kernel/kernel_thread.S | 2 +- arch/ia64/ia32/ia32_entry.S | 3 ++- arch/ia64/kernel/asm-offsets.c | 4 ---- arch/parisc/kernel/entry.S | 4 +--- arch/ppc/kernel/asm-offsets.c | 2 -- arch/ppc/kernel/misc.S | 1 + arch/ppc64/kernel/asm-offsets.c | 3 --- arch/ppc64/kernel/misc.S | 1 + arch/v850/kernel/asm-offsets.c | 4 ---- arch/v850/kernel/entry.S | 1 + include/asm-cris/arch-v10/offset.h | 3 --- include/asm-cris/arch-v32/offset.h | 3 --- include/linux/clone.h | 32 ++++++++++++++++++++++++++++++++ include/linux/sched.h | 30 +----------------------------- 19 files changed, 42 insertions(+), 61 deletions(-) The noise generated by the separation is larger than the avoided duplication. The hardcoded defines actually do need fixing, frv is especially bad, as it even has hardcoded structure offsets. > I have absolutely no problem with different, more > logical splitups, and I'm willing to break down the > entire sched.h if that will help the cause ... so > please enlighten me here ... sched.h is especially challenging due to dependencies between headers under asm and linux. It's not just splitting sched.h, it also requires analyzing its dependencies. bye, Roman - 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/