Re: [PATCH] FRV: Fix the section attribute on UP DECLARE_PER_CPU()

[Ingo Molnar <mingo@elte.hu>]

* David Howells <dhowells@redhat.com> wrote:

> > There's three too 'thick' headers: linux/percpu.h, 
> > linux/prefetch.h and asm/processor.h.
> 
> Yes, I noticed.
> 
> linux/percpu.h needs to be split three ways for instance: 
> definitions, access methods, and alocators.

yeah. Often a super-header has to be split into several basic 
headers or header pairs.

> linux/prefetch.h isn't too bad: what it needs is the prefetch 
> stuff splitting out of asm/processor.h into asm/prefetch.h.

yeah.

> > Please create include/linux/percpu_types.h for basic data types 
> > and simple, self-sufficient primitives. Also have an 
> > include/linux/percpu_api.h or include/linux/percpu.h include 
> > file for convenience/speedup inlines. The latter will only be 
> > included in .c files, where 'combination' of type spaces is not 
> > a problem.
> 
> Not so.  The problem is that various header files make use of 
> per-cpu variable accessors (asm/current.h and asm/thread_info.h to 
> name a couple) to build inline asm.

Hm, what portion did you mark with 'not so'?

inline asm is used in inline functions there, and that is what 
'instantiates' the types in a 'mixed' manner and way below their 
proper hierarchic level as well - creating both a mess and, as mess 
increases above a critical threshold an inevitable circular 
dependency as well.

> Anyway, here are a pair of patches on top of the one I've already 
> sent to Linus.  The second breaks a number of header files into 
> pieces and rearranges the percpu headers to put the DECLARE and 
> DEFINE macros together.
> 
> The first patch could potentially be applied immediately.  It adds 
> #inclusions and forward refs that are required to iron out compile 
> errors from the second patch.
> 
> Note that these only work for the configuration I routinely use on 
> my x86_64 test machine.  It will break all other arches and many 
> other i386 and x86_64 configurations.

I dont disagree, but i'd like to warn that such patches need _way_ 
more testing, these are never same-day obvious patches.

We have split up one big x86 header in this development cycle 
(asm/pgtable.h) and that alone was highly non-trivial and needed 
about a week to settle down, even with intense development and 
testing.

	Ingo