Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932270AbXAOMJa (ORCPT ); Mon, 15 Jan 2007 07:09:30 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932268AbXAOMJa (ORCPT ); Mon, 15 Jan 2007 07:09:30 -0500 Received: from scrub.xs4all.nl ([194.109.195.176]:36148 "EHLO scrub.xs4all.nl" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932240AbXAOMJ3 (ORCPT ); Mon, 15 Jan 2007 07:09:29 -0500 Date: Mon, 15 Jan 2007 13:09:03 +0100 (CET) From: Roman Zippel X-X-Sender: roman@scrub.home To: Linus Torvalds cc: Geert Uytterhoeven , Peter Zijlstra , Andrew Morton , Al Viro , Linux Kernel Development , Linux/m68k Subject: Re: [PATCH] mm: pagefault_{disable,enable}() In-Reply-To: Message-ID: References: <200612071659.kB7GxGHa030259@hera.kernel.org> 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: 2268 Lines: 54 Hi, On Wed, 10 Jan 2007, Linus Torvalds wrote: > > > I think your "current_thread_info()" is broken. No, it's not. What is broken are our header dependencies - we happily mix declarations with implementations. Let's take a simple example like , which is practically included everywhere, but even that already includes 57 other files and depends on 49 config symbols (by comparison for it's 7 other files and 7 symbols). > > But struct task_struct is defined in , which cannot be included > > in due to include recursion hell. > > But why do you need "struct task_struct" at all? > > The reason this doesn't happen on other platforms is that they don't use > "struct task_struct". They use "struct thread_info", which is where the > preemption counter is. > > The problem on m68k i sthat broken indirection through "current", which is > unnecessary. Isn't the thread structure on the stack on m68k too? So you > could do what x86 does, and just do > > movel %a7,%d0 > andl $STACK_MASK,%d0 That's exactly want I want to avoid, thread info and task struct can be accessed via a single register (pointer). > Or, if worst comes to worst, you can just hardcode the offset of the > thread-info pointer in the "struct task_struct". It's the second word > after "state". Ugly, but less so than forcing everybody who does NOT want > to have that big dependency to get it. That still generates worse code, the best solution would be to leave the work to gcc, but that requires it can actually recognize that task struct and thread info need only a single pointer. One possibility would be to do something like ia64 and abuse asm-offsets.h, but then one gets other funny build problems. By far the cleanest solution would be to clean up our damned header dependencies, separating task_struct from sched.h is not that difficult and would give archs far more flexibility how to place task struct and thread info. 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/