linux-kernel - Re: [GIT PULL] x86: more header untangling

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Feb 2009 20:47:19 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jeremy Fitzhardinge <jeremy@...p.org>
Cc:	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86: more header untangling

* Jeremy Fitzhardinge <jeremy@...p.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/