Arnd Bergmann <arnd@xxxxxxxx> wrote:
> 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.
Hmmm... okay. How that is used from an arch that doesn't have an
asm/system.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.
So I saw. It might be worth making an asm/xchg.h and asm/cmpxchg.h for each
arch - or maybe just put both in asm/xchg.h or asm/cmpxchg.h. Where do I
include it from though? One nice thing about sticking them in asm/atomic.h is
that usually gets all instances, and they're frequently used from there. How
about I have asm/atomic.h #include asm/{,cmp}xchg.h?
> > (6) asm/auxvec.h
> >
> > Move AT_VECTOR_SIZE_ARCH here.
>
> These two look suboptimal, but I don't have a better idea either.
Well, AT_VECTOR_SIZE_ARCH is at least auxvec-related, so I think that's
probably in the right place.
> 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?
That might circularly dependerise, but it's worth a try.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
