Re: [RFC][PATCH 00/29] Disintegrate and kill asm/system.h

[Arnd Bergmann]

On Wednesday 07 March 2012, David Howells wrote:
> Here are a bunch of patches to disintegrate asm/system.h into a set of separate
> bits to relieve the problem of circular inclusion dependencies.
>
> The reason for this is that I recently encountered a circular dependency
> problem that came about when I produced some patches to optimise get_order() by
> rewriting it to use ilog2().  This uses bitops - and on the SH arch
> asm/bitops.h drags in asm-generic/get_order.h by a circuituous route involving
> asm/system.h.
>
> The main difficulty seems to be asm/system.h.  It holds a number of low level
> bits with no/few dependencies that are commonly used (eg. memory barriers) and
> a number of bits with more dependencies that aren't used in many places
> (eg. switch_to()).

Excellent series!

One part you were missing seems to be include/asm-generic/system.h, which is used
on openrisc and contains a lot of the things you move to other places. It
would be helpful to split that up as well.

>These patches break asm/system.h up into the following core pieces:
>
>     (1) asm/barrier.h
>
>         Move memory barriers here.  This already done for MIPS and Alpha.
>
>     (2) asm/switch_to.h
>
>         Move switch_to() and related stuff here.
>
>     (3) asm/exec.h
>
>         Move arch_align_stack() here.  Other process execution related bits
>         could perhaps go here from asm/processor.h.
>
>     (4) asm/atomic.h
>
>         Move xchg() and cmpxchg() here as they're full word atomic ops and
>         frequently used by atomic_xchg() and atomic_cmpxchg().

Well, the thing with xchg and cmpxchg is that they operate on arbirary-sized
integers, not atomic_t, unlike everything else in atomic.h.

Some architectures already have an asm/cmpxchg.h, which seems more appropriate
here.

>     (5) asm/bug.h
>
>         Move die() and related bits.
>
>     (6) asm/auxvec.h
>
>         Move AT_VECTOR_SIZE_ARCH here.

These two look suboptimal, but I don't have a better idea either.

> These patches are somewhat inside-out.  They start by removing all the
> inclusions of asm/system.h and then patching up the core files to include the
> right headers and then patching up each arch.  Whilst that's the easiest for
> actually performing this task (as I can use the compiler to find breakages more
> easily), it does mean that the patchset is not bisectable as all arches will be
> broken for a greater or lesser span.
> 
> I'm not sure what's the best way to get around that.  Possibly by rearranging
> things so each arch's asm/system.h is split up, leaving just a file with a
> bunch of #includes - and then delete them all later.  That might not work,
> however, as it may lead to circular deps until asm/system.h is no longer used.
> 

How about adding a '-include asm/system.h' gcc switch for each architecture
in one patch in the beginning, so that the header becomes included all the
time, but then remove that for each arch you go through?

	Arnd
--
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/