From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757112AbZBKTro (ORCPT ); Wed, 11 Feb 2009 14:47:44 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755610AbZBKTrf (ORCPT ); Wed, 11 Feb 2009 14:47:35 -0500 Received: from mx3.mail.elte.hu ([157.181.1.138]:45123 "EHLO mx3.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755446AbZBKTrf (ORCPT ); Wed, 11 Feb 2009 14:47:35 -0500 Date: Wed, 11 Feb 2009 20:47:19 +0100 From: Ingo Molnar To: Jeremy Fitzhardinge Cc: the arch/x86 maintainers , Linux Kernel Mailing List Subject: Re: [GIT PULL] x86: more header untangling Message-ID: <20090211194719.GA25968@elte.hu> References: <4991D626.5040009@goop.org> <20090211100323.GE20518@elte.hu> <49930485.3070204@goop.org> <20090211171439.GA9185@elte.hu> <49931F04.80605@goop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49931F04.80605@goop.org> User-Agent: Mutt/1.5.18 (2008-05-17) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Jeremy Fitzhardinge wrote: > Ingo Molnar wrote: >> constants can be considered data types too. > > Huh, that's a pretty broad definition of "type", to the degree that's > its fairly counter-intuitive and misleading. But I don't care that much. Well, it's a stretch, but constants of a specific type are a lot closer to the notion of 'type' than to the notion of 'function/method/code'. The problem we are trying to solve here is dependency hell. Dependencies get generated by methods, which are functions/operators defined over multiple type-spaces. For example: static inline void mm_init_owner(struct mm_struct *mm, struct task_struct *p) Is a (mathematical) function defined over the: (struct mm_struct x struct task_struct) two-dimensional type space. The problem that this inline causes is that it couples two, otherwise largely independent type spaces: 'struct mm_struct' and 'struct task_struct'. Given a high enough count of such random couplings, and given the fact that any two subsystems will have some method that connects them, it can be seen that to be able to define arbitrary inline methods, we need to include pretty much all headers into 'super-headers' like sched.h or mm.h. Pure types are simple constructs: they only depend on the particular types they embedd. They dont depend on the types that happen to embedd them. Same goes for constants: they are of a specific type, and hence are more similar to the 'type' notion than the 'method' notion. So regardless of how we call them, we want constants to be near the types they are related to. They do not cause dependency hell, hence they can be in the _types.h headers. Another possibility would be to make a further distinction between 'local methods' and 'compound methods'. Local methods are the ones that only relate to a given data type. Compound methods combine multiple types. We could allow local methods in type headers, and forbid compound methods. Ingo