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

From: Ingo Molnar
Date: Thu May 14 2015 - 06:02:42 EST

* Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Wed, 13 May 2015 09:27:57 -0700 Josh Triplett <josh@xxxxxxxxxxxxxxxx> 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.

Ok, agreed, I've solved these problems by creating a per feature
broken out directory hieararchy, see my next patch submission.

> 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

Ok, added.


Ok, added.


Ok, added.


So this does not appear to be a feature per se: architectures that
don't define __HAVE_ARCH_GATE_AREA fall back to the generic one. Or is
it expected for every architecture to provide its own?


Does not seem to be upstream.


Yeah, that's already included in v6.


So AFAICS this feature is an arch opt-in, on the basis of whether GCC
does the right thing or not.

We'd need a separate config switch: ARCH_DONT_USE_BUILTIN_BSWAP to
make a distinction between architectures that have made an informed
decision to not support it, versus architectures that have not
bothered so far.


Ok, added.


Ok, added.


So, no architecture supports this yet- but added.


Agreed and v6 already includes this.


So this isn't really a feature, but a facility that an architecture
might have to provide if it has a quirk. Only ia64 has that at the


Not upstream yet it appears.


Ok, added.


So this too is a quirk, for PowerPC, which does not maintain the
memory layout in the resource tree.

> and things which don't contain ARCH

So this is a generic, RCU based fast-GUP facility - but architectures
may implement their own get_user_pages_fast() facilites, such as x86
which does it lock-less.

So I'm not sure what to flag here: perhaps architectures that don't
offer get_user_pages_fast() at all?


So this is related to HAVE_GENERIC_RCU_GUP: architectures that do RCU
based GUP will want to use HAVE_RCU_TABLE_FREE.


double ;-)


So I think the generic clock framework first needs to be integrated
with core timekeeping before we start requiring it from architectures.


Agreed - already in -v6.


Ok, added.

> 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....

Hm, yes. If you give me a rough list then I can try to map them out as

Once we have the initial feature collection done it will be a lot
easier going forward: anything missing or inaccurate can be added to
or fixed in its own file.

> 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.

I hope you'll like the structure of -v7 better :-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at