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, 07 Mar 2012 22:40:06 +0000
From:	David Howells <dhowells@...hat.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	dhowells@...hat.com, paul.gortmaker@...driver.com, hpa@...or.com,
	torvalds@...ux-foundation.org, sfr@...b.auug.org.au,
	mingo@...hat.com, tglx@...utronix.de, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [RFC][PATCH 00/29] Disintegrate and kill asm/system.h

Arnd Bergmann <arnd@...db.de> 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-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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ