Re: [GIT PULL] x86: more header untangling

[Ingo Molnar]

* Jeremy Fitzhardinge <jeremy@xxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/