linux-kernel - Re: [RFC PATCH v6] Documentation/arch: Add Documentation/arch-features.txt

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 for Android: free password hash cracker in your pocket

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

Message-Id: <20150513150523.ddd65d7cd51f820b78f0c8e3@linux-foundation.org>
Date:	Wed, 13 May 2015 15:05:23 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Josh Triplett <josh@...htriplett.org>
Cc:	Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...en8.de>,
	Jonathan Corbet <corbet@....net>,
	Peter Zijlstra <peterz@...radead.org>,
	Andy Lutomirski <luto@...capital.net>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org,
	x86@...nel.org, linux-arch@...r.kernel.org
Subject: Re: [RFC PATCH v6] Documentation/arch: Add
 Documentation/arch-features.txt

On Wed, 13 May 2015 09:27:57 -0700 Josh Triplett <josh@...htriplett.org> wrote:

> If we can't generate this, then the ASCII-art style and right-aligned
> feature names seems *really* likely to produce spurious conflicts,
> especially when adding a feature to the list.  Even though it would
> produce a much longer file, would you consider dropping the tables and
> just having a section per feature?

me2.  The patch conflicts are going to be pretty bad.

I'd also prefer a format which allows us to add useful notes - it's a
bit hostile to say "thou shalt implement X" without providing any info
about how to do so.  Where do we tell maintainers that there's a handy
test app in tools/testing/selftests which they should use?

This way, I can bug patch submitters with "hey, you forgot to update
Documentation/arch-features.txt" and they will add useful info while
it's all still hot in their minds.



And there's a ton of stuff which can go in here, much of it not
immediately apparent.

Just grepping 9 months worth of the stuff I've handled, I'm seeing
things like

HAVE_ARCH_KASAN
__HAVE_ARCH_PMDP_SPLITTING_FLUSH
__HAVE_ARCH_PTE_SPECIAL
__HAVE_ARCH_GATE_AREA
ARCH_HAVE_ELF_ASLR
ARCH_HAS_GCOV_PROFILE_ALL
CONFIG_ARCH_USE_BUILTIN_BSWAP
HAVE_ARCH_HUGE_VMAP
ARCH_HAS_SG_CHAIN
__HAVE_ARCH_STRNCASECMP
ARCH_HAS_ELF_RANDOMIZE
CONFIG_HAVE_ARCH_EARLY_PFN_TO_NID
ARCH_SUPPORTS_DEFERRED_STRUCT_PAGE_INIT
CONFIG_ARCH_USES_PG_UNCACHED
CONFIG_ARCH_HAS_WALK_MEMORY

and things which don't contain ARCH

HAVE_GENERIC_RCU_GUP
HAVE_RCU_TABLE_FREE
HAVE_GENERIC_RCU_GUP
CONFIG_HAVE_CLK
CONFIG_HAVE_IOREMAP_PROT
CONFIG_HAVE_MEMBLOCK_NODE_MAP

And then there's the increasingly common

arch/include/asm/foo.h:

	static inline void wibble(...)
	{
		...
	}
	#define wibble wibble

include/linux/foo.h:

	#ifndef wibble
	static inline void wibble(...)
	{
		...
	}
	#define wibble
	#endif

which is going to be hard to grep for....


ugh, this thing's going to be enormous.  People will go insane reading
it, so each section should have a sentence describing what the feature
does so maintainers can make quick decisions about whether they should
bother.
--
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/