Re: [RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

[Ingo Molnar]

* Andrea Parri  wrote:

> On Wed, Apr 04, 2018 at 06:56:32AM +0200, Ingo Molnar wrote:
> > 
> > * Andrea Parri  wrote:
> > 
> > > In Ingo's words [1]:
> > > 
> > >   "[...]  what should be done instead is to write a script that refreshes
> > >all the arch-support.txt files in-place. [...]
> > > 
> > >It's OK for the script to have various quirks for weirdly implemented
> > >features and exceptions: i.e. basically whenever it gets a feature 
> > > wrong,
> > >we can just tweak the script with quirks to make it all work out of 
> > > box.
> > > 
> > >[...]  But in the end there should only be a single new script:
> > > 
> > >  Documentation/features/scripts/features-refresh.sh
> > > 
> > >... which operates on the arch-support.txt files and refreshes them in
> > >place, and which, after all the refreshes have been committed, should
> > >produce an empty 'git diff' result."
> > > 
> > >   "[...]  New features can then be added by basically just creating a
> > >header-only arch-support.txt file, such as:
> > > 
> > >  triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
> > >  #
> > >  # Feature name:  shiny new fubar kernel feature
> > >  # Kconfig:   ARCH_USE_FUBAR
> > >  # description:   arch supports the fubar feature
> > >  #
> > > 
> > >And running Documentation/features/scripts/features-refresh.sh would
> > >auto-generate the arch support matrix. [...]
> > >  
> > >This way we soft- decouple the refreshing of the entries from the
> > >introduction of the features, while still making it all easy to keep
> > >sync and to extend."
> > > 
> > > This RFC presents a first attempt to implement such a feature/script, and
> > > applies it script on top of Arnd's:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
> > > arch-removal
> > > 
> > > Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes 
> > > the
> > > "BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
> > > "eBPF-JIT".  Patch 3/3 presents the results of running the script; this 
> > > run
> > > also printed to standard output the following warnings:
> > > 
> > >   WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
> > >   WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
> > >   WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
> > >   WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig
> > > 
> > > (I'm sending these patches with empty commit messagges, for early 
> > > feedback:
> > >  I'll fill in these messages in subsequent versions if this makes 
> > > sense...)
> > > 
> > > Cheers,
> > >   Andrea
> > > 
> > > Andrea Parri (3):
> > >   Documentation/features: Add script that refreshes the arch support 
> > > status files in place
> > >   Documentation/features/core: Add arch support status files for 
> > > 'cBPF-JIT' and 'eBPF-JIT'
> > >   Documentation/features: Refresh and auto-generate the arch support 
> > > status files in place
> > 
> > Ok, this series is really impressive at its RFC stage already!
> > 
> > Beyond fixing those warnings, I'd also suggest another change: please make 
> > the 
> > new BPF features patch the last one, so that the 'refresh' patch shows how 
> > much 
> > original bit-rot we gathered recently.
> > 
> > The 'new features' patch should then also include the result of also 
> > running the 
> > script, i.e. a single patch adding the base fields and the generated parts 
> > as 
> > well. That will be the usual development flow anyway - people won't do 
> > two-part 
> > patches just to show which bits are by hand and which are auto-generated.
> 
> Yes, I'll do.
> 
> Let me ask some hints about the warnings, as I'm not sure how to 'fix' them;
> we have:
> 
>   a) __HAVE_ARCH_STRNCASECMP
>  __HAVE_ARCH_PTE_SPECIAL
> 
>   b) Optimized asm/rwsem.h
> 
>   c) !ARCH_USES_GETTIMEOFFSET  
> 
> For (c), I see two options:
> 
>   1. replace that with 'ARCH_USES_GETTIMEOFFSET' (and update the status
>  matrix accordingly)
> 
>   2. add logics/code to the script to handle simple boolean expressions
>  (mmh, this could get nasty really soon... let's say: limiting to a
>  leading '!', to start with ;)

Yeah, so the problem here is that the feature is the _lack_ of legacy 
ARCH_USES_GETTIMEOFFSET, so we cannot just invert the check - the output would 
be 
rather confusing ...

Negating the switch in the kernel would force us to add a "arch uses modern 
timekeeping" flag to every other architecture - not a very good solution.

I'd suggest adding support for a simple '!' operator with very strict syntax - 
nothing more. (This would also be useful for (b), see below.)

> For (a), I realize that 'grep-ing' the macros in arch-specific _sources_
> does serve the purpose of producing the hard-coded status matrices; but
> is 

Re: [RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

[Ingo Molnar]

* Andrea Parri  wrote:

> On Wed, Apr 04, 2018 at 06:56:32AM +0200, Ingo Molnar wrote:
> > 
> > * Andrea Parri  wrote:
> > 
> > > In Ingo's words [1]:
> > > 
> > >   "[...]  what should be done instead is to write a script that refreshes
> > >all the arch-support.txt files in-place. [...]
> > > 
> > >It's OK for the script to have various quirks for weirdly implemented
> > >features and exceptions: i.e. basically whenever it gets a feature 
> > > wrong,
> > >we can just tweak the script with quirks to make it all work out of 
> > > box.
> > > 
> > >[...]  But in the end there should only be a single new script:
> > > 
> > >  Documentation/features/scripts/features-refresh.sh
> > > 
> > >... which operates on the arch-support.txt files and refreshes them in
> > >place, and which, after all the refreshes have been committed, should
> > >produce an empty 'git diff' result."
> > > 
> > >   "[...]  New features can then be added by basically just creating a
> > >header-only arch-support.txt file, such as:
> > > 
> > >  triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
> > >  #
> > >  # Feature name:  shiny new fubar kernel feature
> > >  # Kconfig:   ARCH_USE_FUBAR
> > >  # description:   arch supports the fubar feature
> > >  #
> > > 
> > >And running Documentation/features/scripts/features-refresh.sh would
> > >auto-generate the arch support matrix. [...]
> > >  
> > >This way we soft- decouple the refreshing of the entries from the
> > >introduction of the features, while still making it all easy to keep
> > >sync and to extend."
> > > 
> > > This RFC presents a first attempt to implement such a feature/script, and
> > > applies it script on top of Arnd's:
> > > 
> > >   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
> > > arch-removal
> > > 
> > > Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes 
> > > the
> > > "BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
> > > "eBPF-JIT".  Patch 3/3 presents the results of running the script; this 
> > > run
> > > also printed to standard output the following warnings:
> > > 
> > >   WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
> > >   WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
> > >   WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
> > >   WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig
> > > 
> > > (I'm sending these patches with empty commit messagges, for early 
> > > feedback:
> > >  I'll fill in these messages in subsequent versions if this makes 
> > > sense...)
> > > 
> > > Cheers,
> > >   Andrea
> > > 
> > > Andrea Parri (3):
> > >   Documentation/features: Add script that refreshes the arch support 
> > > status files in place
> > >   Documentation/features/core: Add arch support status files for 
> > > 'cBPF-JIT' and 'eBPF-JIT'
> > >   Documentation/features: Refresh and auto-generate the arch support 
> > > status files in place
> > 
> > Ok, this series is really impressive at its RFC stage already!
> > 
> > Beyond fixing those warnings, I'd also suggest another change: please make 
> > the 
> > new BPF features patch the last one, so that the 'refresh' patch shows how 
> > much 
> > original bit-rot we gathered recently.
> > 
> > The 'new features' patch should then also include the result of also 
> > running the 
> > script, i.e. a single patch adding the base fields and the generated parts 
> > as 
> > well. That will be the usual development flow anyway - people won't do 
> > two-part 
> > patches just to show which bits are by hand and which are auto-generated.
> 
> Yes, I'll do.
> 
> Let me ask some hints about the warnings, as I'm not sure how to 'fix' them;
> we have:
> 
>   a) __HAVE_ARCH_STRNCASECMP
>  __HAVE_ARCH_PTE_SPECIAL
> 
>   b) Optimized asm/rwsem.h
> 
>   c) !ARCH_USES_GETTIMEOFFSET  
> 
> For (c), I see two options:
> 
>   1. replace that with 'ARCH_USES_GETTIMEOFFSET' (and update the status
>  matrix accordingly)
> 
>   2. add logics/code to the script to handle simple boolean expressions
>  (mmh, this could get nasty really soon... let's say: limiting to a
>  leading '!', to start with ;)

Yeah, so the problem here is that the feature is the _lack_ of legacy 
ARCH_USES_GETTIMEOFFSET, so we cannot just invert the check - the output would 
be 
rather confusing ...

Negating the switch in the kernel would force us to add a "arch uses modern 
timekeeping" flag to every other architecture - not a very good solution.

I'd suggest adding support for a simple '!' operator with very strict syntax - 
nothing more. (This would also be useful for (b), see below.)

> For (a), I realize that 'grep-ing' the macros in arch-specific _sources_
> does serve the purpose of producing the hard-coded status matrices; but
> is this a reasonable approach? (e.g., can produce 'false-positives'?)

I'd 

Re: [RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

[Andrea Parri]

On Wed, Apr 04, 2018 at 06:56:32AM +0200, Ingo Molnar wrote:
> 
> * Andrea Parri  wrote:
> 
> > In Ingo's words [1]:
> > 
> >   "[...]  what should be done instead is to write a script that refreshes
> >all the arch-support.txt files in-place. [...]
> > 
> >It's OK for the script to have various quirks for weirdly implemented
> >features and exceptions: i.e. basically whenever it gets a feature wrong,
> >we can just tweak the script with quirks to make it all work out of box.
> > 
> >[...]  But in the end there should only be a single new script:
> > 
> >  Documentation/features/scripts/features-refresh.sh
> > 
> >... which operates on the arch-support.txt files and refreshes them in
> >place, and which, after all the refreshes have been committed, should
> >produce an empty 'git diff' result."
> > 
> >   "[...]  New features can then be added by basically just creating a
> >header-only arch-support.txt file, such as:
> > 
> >  triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
> >  #
> >  # Feature name:  shiny new fubar kernel feature
> >  # Kconfig:   ARCH_USE_FUBAR
> >  # description:   arch supports the fubar feature
> >  #
> > 
> >And running Documentation/features/scripts/features-refresh.sh would
> >auto-generate the arch support matrix. [...]
> >  
> >This way we soft- decouple the refreshing of the entries from the
> >introduction of the features, while still making it all easy to keep
> >sync and to extend."
> > 
> > This RFC presents a first attempt to implement such a feature/script, and
> > applies it script on top of Arnd's:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
> > arch-removal
> > 
> > Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes the
> > "BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
> > "eBPF-JIT".  Patch 3/3 presents the results of running the script; this run
> > also printed to standard output the following warnings:
> > 
> >   WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
> >   WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
> >   WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
> >   WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig
> > 
> > (I'm sending these patches with empty commit messagges, for early feedback:
> >  I'll fill in these messages in subsequent versions if this makes sense...)
> > 
> > Cheers,
> >   Andrea
> > 
> > Andrea Parri (3):
> >   Documentation/features: Add script that refreshes the arch support status 
> > files in place
> >   Documentation/features/core: Add arch support status files for 'cBPF-JIT' 
> > and 'eBPF-JIT'
> >   Documentation/features: Refresh and auto-generate the arch support status 
> > files in place
> 
> Ok, this series is really impressive at its RFC stage already!
> 
> Beyond fixing those warnings, I'd also suggest another change: please make 
> the 
> new BPF features patch the last one, so that the 'refresh' patch shows how 
> much 
> original bit-rot we gathered recently.
> 
> The 'new features' patch should then also include the result of also running 
> the 
> script, i.e. a single patch adding the base fields and the generated parts as 
> well. That will be the usual development flow anyway - people won't do 
> two-part 
> patches just to show which bits are by hand and which are auto-generated.

Yes, I'll do.

Let me ask some hints about the warnings, as I'm not sure how to 'fix' them;
we have:

  a) __HAVE_ARCH_STRNCASECMP
 __HAVE_ARCH_PTE_SPECIAL

  b) Optimized asm/rwsem.h

  c) !ARCH_USES_GETTIMEOFFSET  

For (c), I see two options:

  1. replace that with 'ARCH_USES_GETTIMEOFFSET' (and update the status
 matrix accordingly)

  2. add logics/code to the script to handle simple boolean expressions
 (mmh, this could get nasty really soon... let's say: limiting to a
 leading '!', to start with ;)

For (a), I realize that 'grep-ing' the macros in arch-specific _sources_
does serve the purpose of producing the hard-coded status matrices; but
is this a reasonable approach? (e.g., can produce 'false-positives'?)

What could it be a suitable solution for (b)? are there Kconfig options
which I could in place of that expression? some other suggestion?

Thanks,
  Andrea


> 
> Thanks,
> 
>   Ingo

Re: [RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

[Andrea Parri]

On Wed, Apr 04, 2018 at 06:56:32AM +0200, Ingo Molnar wrote:
> 
> * Andrea Parri  wrote:
> 
> > In Ingo's words [1]:
> > 
> >   "[...]  what should be done instead is to write a script that refreshes
> >all the arch-support.txt files in-place. [...]
> > 
> >It's OK for the script to have various quirks for weirdly implemented
> >features and exceptions: i.e. basically whenever it gets a feature wrong,
> >we can just tweak the script with quirks to make it all work out of box.
> > 
> >[...]  But in the end there should only be a single new script:
> > 
> >  Documentation/features/scripts/features-refresh.sh
> > 
> >... which operates on the arch-support.txt files and refreshes them in
> >place, and which, after all the refreshes have been committed, should
> >produce an empty 'git diff' result."
> > 
> >   "[...]  New features can then be added by basically just creating a
> >header-only arch-support.txt file, such as:
> > 
> >  triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
> >  #
> >  # Feature name:  shiny new fubar kernel feature
> >  # Kconfig:   ARCH_USE_FUBAR
> >  # description:   arch supports the fubar feature
> >  #
> > 
> >And running Documentation/features/scripts/features-refresh.sh would
> >auto-generate the arch support matrix. [...]
> >  
> >This way we soft- decouple the refreshing of the entries from the
> >introduction of the features, while still making it all easy to keep
> >sync and to extend."
> > 
> > This RFC presents a first attempt to implement such a feature/script, and
> > applies it script on top of Arnd's:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
> > arch-removal
> > 
> > Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes the
> > "BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
> > "eBPF-JIT".  Patch 3/3 presents the results of running the script; this run
> > also printed to standard output the following warnings:
> > 
> >   WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
> >   WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
> >   WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
> >   WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig
> > 
> > (I'm sending these patches with empty commit messagges, for early feedback:
> >  I'll fill in these messages in subsequent versions if this makes sense...)
> > 
> > Cheers,
> >   Andrea
> > 
> > Andrea Parri (3):
> >   Documentation/features: Add script that refreshes the arch support status 
> > files in place
> >   Documentation/features/core: Add arch support status files for 'cBPF-JIT' 
> > and 'eBPF-JIT'
> >   Documentation/features: Refresh and auto-generate the arch support status 
> > files in place
> 
> Ok, this series is really impressive at its RFC stage already!
> 
> Beyond fixing those warnings, I'd also suggest another change: please make 
> the 
> new BPF features patch the last one, so that the 'refresh' patch shows how 
> much 
> original bit-rot we gathered recently.
> 
> The 'new features' patch should then also include the result of also running 
> the 
> script, i.e. a single patch adding the base fields and the generated parts as 
> well. That will be the usual development flow anyway - people won't do 
> two-part 
> patches just to show which bits are by hand and which are auto-generated.

Yes, I'll do.

Let me ask some hints about the warnings, as I'm not sure how to 'fix' them;
we have:

  a) __HAVE_ARCH_STRNCASECMP
 __HAVE_ARCH_PTE_SPECIAL

  b) Optimized asm/rwsem.h

  c) !ARCH_USES_GETTIMEOFFSET  

For (c), I see two options:

  1. replace that with 'ARCH_USES_GETTIMEOFFSET' (and update the status
 matrix accordingly)

  2. add logics/code to the script to handle simple boolean expressions
 (mmh, this could get nasty really soon... let's say: limiting to a
 leading '!', to start with ;)

For (a), I realize that 'grep-ing' the macros in arch-specific _sources_
does serve the purpose of producing the hard-coded status matrices; but
is this a reasonable approach? (e.g., can produce 'false-positives'?)

What could it be a suitable solution for (b)? are there Kconfig options
which I could in place of that expression? some other suggestion?

Thanks,
  Andrea


> 
> Thanks,
> 
>   Ingo

Re: [RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

[Ingo Molnar]

* Andrea Parri  wrote:

> In Ingo's words [1]:
> 
>   "[...]  what should be done instead is to write a script that refreshes
>all the arch-support.txt files in-place. [...]
> 
>It's OK for the script to have various quirks for weirdly implemented
>features and exceptions: i.e. basically whenever it gets a feature wrong,
>we can just tweak the script with quirks to make it all work out of box.
> 
>[...]  But in the end there should only be a single new script:
> 
>  Documentation/features/scripts/features-refresh.sh
> 
>... which operates on the arch-support.txt files and refreshes them in
>place, and which, after all the refreshes have been committed, should
>produce an empty 'git diff' result."
> 
>   "[...]  New features can then be added by basically just creating a
>header-only arch-support.txt file, such as:
> 
>  triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
>  #
>  # Feature name:  shiny new fubar kernel feature
>  # Kconfig:   ARCH_USE_FUBAR
>  # description:   arch supports the fubar feature
>  #
> 
>And running Documentation/features/scripts/features-refresh.sh would
>auto-generate the arch support matrix. [...]
>  
>This way we soft- decouple the refreshing of the entries from the
>introduction of the features, while still making it all easy to keep
>sync and to extend."
> 
> This RFC presents a first attempt to implement such a feature/script, and
> applies it script on top of Arnd's:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
> arch-removal
> 
> Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes the
> "BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
> "eBPF-JIT".  Patch 3/3 presents the results of running the script; this run
> also printed to standard output the following warnings:
> 
>   WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
>   WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
>   WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
>   WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig
> 
> (I'm sending these patches with empty commit messagges, for early feedback:
>  I'll fill in these messages in subsequent versions if this makes sense...)
> 
> Cheers,
>   Andrea
> 
> Andrea Parri (3):
>   Documentation/features: Add script that refreshes the arch support status 
> files in place
>   Documentation/features/core: Add arch support status files for 'cBPF-JIT' 
> and 'eBPF-JIT'
>   Documentation/features: Refresh and auto-generate the arch support status 
> files in place

Ok, this series is really impressive at its RFC stage already!

Beyond fixing those warnings, I'd also suggest another change: please make the 
new BPF features patch the last one, so that the 'refresh' patch shows how much 
original bit-rot we gathered recently.

The 'new features' patch should then also include the result of also running 
the 
script, i.e. a single patch adding the base fields and the generated parts as 
well. That will be the usual development flow anyway - people won't do two-part 
patches just to show which bits are by hand and which are auto-generated.

Thanks,

Ingo

Re: [RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

[Ingo Molnar]

* Andrea Parri  wrote:

> In Ingo's words [1]:
> 
>   "[...]  what should be done instead is to write a script that refreshes
>all the arch-support.txt files in-place. [...]
> 
>It's OK for the script to have various quirks for weirdly implemented
>features and exceptions: i.e. basically whenever it gets a feature wrong,
>we can just tweak the script with quirks to make it all work out of box.
> 
>[...]  But in the end there should only be a single new script:
> 
>  Documentation/features/scripts/features-refresh.sh
> 
>... which operates on the arch-support.txt files and refreshes them in
>place, and which, after all the refreshes have been committed, should
>produce an empty 'git diff' result."
> 
>   "[...]  New features can then be added by basically just creating a
>header-only arch-support.txt file, such as:
> 
>  triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
>  #
>  # Feature name:  shiny new fubar kernel feature
>  # Kconfig:   ARCH_USE_FUBAR
>  # description:   arch supports the fubar feature
>  #
> 
>And running Documentation/features/scripts/features-refresh.sh would
>auto-generate the arch support matrix. [...]
>  
>This way we soft- decouple the refreshing of the entries from the
>introduction of the features, while still making it all easy to keep
>sync and to extend."
> 
> This RFC presents a first attempt to implement such a feature/script, and
> applies it script on top of Arnd's:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
> arch-removal
> 
> Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes the
> "BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
> "eBPF-JIT".  Patch 3/3 presents the results of running the script; this run
> also printed to standard output the following warnings:
> 
>   WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
>   WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
>   WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
>   WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig
> 
> (I'm sending these patches with empty commit messagges, for early feedback:
>  I'll fill in these messages in subsequent versions if this makes sense...)
> 
> Cheers,
>   Andrea
> 
> Andrea Parri (3):
>   Documentation/features: Add script that refreshes the arch support status 
> files in place
>   Documentation/features/core: Add arch support status files for 'cBPF-JIT' 
> and 'eBPF-JIT'
>   Documentation/features: Refresh and auto-generate the arch support status 
> files in place

Ok, this series is really impressive at its RFC stage already!

Beyond fixing those warnings, I'd also suggest another change: please make the 
new BPF features patch the last one, so that the 'refresh' patch shows how much 
original bit-rot we gathered recently.

The 'new features' patch should then also include the result of also running 
the 
script, i.e. a single patch adding the base fields and the generated parts as 
well. That will be the usual development flow anyway - people won't do two-part 
patches just to show which bits are by hand and which are auto-generated.

Thanks,

Ingo

[RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

[Andrea Parri]

In Ingo's words [1]:

  "[...]  what should be done instead is to write a script that refreshes
   all the arch-support.txt files in-place. [...]

   It's OK for the script to have various quirks for weirdly implemented
   features and exceptions: i.e. basically whenever it gets a feature wrong,
   we can just tweak the script with quirks to make it all work out of box.

   [...]  But in the end there should only be a single new script:

 Documentation/features/scripts/features-refresh.sh

   ... which operates on the arch-support.txt files and refreshes them in
   place, and which, after all the refreshes have been committed, should
   produce an empty 'git diff' result."

  "[...]  New features can then be added by basically just creating a
   header-only arch-support.txt file, such as:

 triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
 #
 # Feature name:  shiny new fubar kernel feature
 # Kconfig:   ARCH_USE_FUBAR
 # description:   arch supports the fubar feature
 #

   And running Documentation/features/scripts/features-refresh.sh would
   auto-generate the arch support matrix. [...]
 
   This way we soft- decouple the refreshing of the entries from the
   introduction of the features, while still making it all easy to keep
   sync and to extend."

This RFC presents a first attempt to implement such a feature/script, and
applies it script on top of Arnd's:

  git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
arch-removal

Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes the
"BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
"eBPF-JIT".  Patch 3/3 presents the results of running the script; this run
also printed to standard output the following warnings:

  WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
  WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
  WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
  WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig

(I'm sending these patches with empty commit messagges, for early feedback:
 I'll fill in these messages in subsequent versions if this makes sense...)

Cheers,
  Andrea

Andrea Parri (3):
  Documentation/features: Add script that refreshes the arch support
status files in place
  Documentation/features/core: Add arch support status files for
'cBPF-JIT' and 'eBPF-JIT'
  Documentation/features: Refresh and auto-generate the arch support
status files in place

 .../features/core/BPF-JIT/arch-support.txt | 31 
 .../features/core/cBPF-JIT/arch-support.txt| 32 +
 .../features/core/eBPF-JIT/arch-support.txt| 32 +
 .../core/generic-idle-thread/arch-support.txt  |  3 +-
 .../features/core/jump-labels/arch-support.txt |  1 +
 .../features/core/tracehook/arch-support.txt   |  1 +
 .../features/debug/KASAN/arch-support.txt  |  3 +-
 .../debug/gcov-profile-all/arch-support.txt|  1 +
 Documentation/features/debug/kgdb/arch-support.txt |  3 +-
 .../debug/kprobes-on-ftrace/arch-support.txt   |  1 +
 .../features/debug/kprobes/arch-support.txt|  3 +-
 .../features/debug/kretprobes/arch-support.txt |  3 +-
 .../features/debug/optprobes/arch-support.txt  |  3 +-
 .../features/debug/stackprotector/arch-support.txt |  1 +
 .../features/debug/uprobes/arch-support.txt|  5 +-
 .../debug/user-ret-profiler/arch-support.txt   |  1 +
 .../features/io/dma-api-debug/arch-support.txt |  1 +
 .../features/io/dma-contiguous/arch-support.txt|  3 +-
 .../features/io/sg-chain/arch-support.txt  |  1 +
 .../features/lib/strncasecmp/arch-support.txt  |  1 +
 .../locking/cmpxchg-local/arch-support.txt |  3 +-
 .../features/locking/lockdep/arch-support.txt  |  3 +-
 .../locking/queued-rwlocks/arch-support.txt|  9 ++--
 .../locking/queued-spinlocks/arch-support.txt  |  7 +--
 .../locking/rwsem-optimized/arch-support.txt   |  1 +
 .../features/perf/kprobes-event/arch-support.txt   |  5 +-
 .../features/perf/perf-regs/arch-support.txt   |  3 +-
 .../features/perf/perf-stackdump/arch-support.txt  |  3 +-
 .../sched/membarrier-sync-core/arch-support.txt|  1 +
 .../features/sched/numa-balancing/arch-support.txt |  5 +-
 Documentation/features/scripts/features-refresh.sh | 55 ++
 .../seccomp/seccomp-filter/arch-support.txt|  5 +-
 .../time/arch-tick-broadcast/arch-support.txt  |  3 +-
 .../features/time/clockevents/arch-support.txt |  3 +-
 .../time/context-tracking/arch-support.txt |  1 +
 .../features/time/irq-time-acct/arch-support.txt   |  3 +-
 .../time/modern-timekeeping/arch-support.txt   |  1 +
 .../features/time/virt-cpuacct/arch-support.txt|  1 +
 .../features/vm/ELF-ASLR/arch-support.txt  |  3 +-
 .../features/vm/PG_uncached/arch-support.txt   |  1 +
 

[RFC PATCH 0/3] Documentation/features: Provide and apply "features-refresh.sh"

[Andrea Parri]

In Ingo's words [1]:

  "[...]  what should be done instead is to write a script that refreshes
   all the arch-support.txt files in-place. [...]

   It's OK for the script to have various quirks for weirdly implemented
   features and exceptions: i.e. basically whenever it gets a feature wrong,
   we can just tweak the script with quirks to make it all work out of box.

   [...]  But in the end there should only be a single new script:

 Documentation/features/scripts/features-refresh.sh

   ... which operates on the arch-support.txt files and refreshes them in
   place, and which, after all the refreshes have been committed, should
   produce an empty 'git diff' result."

  "[...]  New features can then be added by basically just creating a
   header-only arch-support.txt file, such as:

 triton:~/tip/Documentation/features> cat foo/bar/arch-support.txt
 #
 # Feature name:  shiny new fubar kernel feature
 # Kconfig:   ARCH_USE_FUBAR
 # description:   arch supports the fubar feature
 #

   And running Documentation/features/scripts/features-refresh.sh would
   auto-generate the arch support matrix. [...]
 
   This way we soft- decouple the refreshing of the entries from the
   introduction of the features, while still making it all easy to keep
   sync and to extend."

This RFC presents a first attempt to implement such a feature/script, and
applies it script on top of Arnd's:

  git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic.git 
arch-removal

Patch 1/3 provides the "features-refresh.sh" script.  Patch 2/3 removes the
"BPF-JIT" feature file and it creates header-only files for "cBPF-JIT" and
"eBPF-JIT".  Patch 3/3 presents the results of running the script; this run
also printed to standard output the following warnings:

  WARNING: '__HAVE_ARCH_STRNCASECMP' is not a valid Kconfig
  WARNING: 'Optimized asm/rwsem.h' is not a valid Kconfig
  WARNING: '!ARCH_USES_GETTIMEOFFSET' is not a valid Kconfig
  WARNING: '__HAVE_ARCH_PTE_SPECIAL' is not a valid Kconfig

(I'm sending these patches with empty commit messagges, for early feedback:
 I'll fill in these messages in subsequent versions if this makes sense...)

Cheers,
  Andrea

Andrea Parri (3):
  Documentation/features: Add script that refreshes the arch support
status files in place
  Documentation/features/core: Add arch support status files for
'cBPF-JIT' and 'eBPF-JIT'
  Documentation/features: Refresh and auto-generate the arch support
status files in place

 .../features/core/BPF-JIT/arch-support.txt | 31 
 .../features/core/cBPF-JIT/arch-support.txt| 32 +
 .../features/core/eBPF-JIT/arch-support.txt| 32 +
 .../core/generic-idle-thread/arch-support.txt  |  3 +-
 .../features/core/jump-labels/arch-support.txt |  1 +
 .../features/core/tracehook/arch-support.txt   |  1 +
 .../features/debug/KASAN/arch-support.txt  |  3 +-
 .../debug/gcov-profile-all/arch-support.txt|  1 +
 Documentation/features/debug/kgdb/arch-support.txt |  3 +-
 .../debug/kprobes-on-ftrace/arch-support.txt   |  1 +
 .../features/debug/kprobes/arch-support.txt|  3 +-
 .../features/debug/kretprobes/arch-support.txt |  3 +-
 .../features/debug/optprobes/arch-support.txt  |  3 +-
 .../features/debug/stackprotector/arch-support.txt |  1 +
 .../features/debug/uprobes/arch-support.txt|  5 +-
 .../debug/user-ret-profiler/arch-support.txt   |  1 +
 .../features/io/dma-api-debug/arch-support.txt |  1 +
 .../features/io/dma-contiguous/arch-support.txt|  3 +-
 .../features/io/sg-chain/arch-support.txt  |  1 +
 .../features/lib/strncasecmp/arch-support.txt  |  1 +
 .../locking/cmpxchg-local/arch-support.txt |  3 +-
 .../features/locking/lockdep/arch-support.txt  |  3 +-
 .../locking/queued-rwlocks/arch-support.txt|  9 ++--
 .../locking/queued-spinlocks/arch-support.txt  |  7 +--
 .../locking/rwsem-optimized/arch-support.txt   |  1 +
 .../features/perf/kprobes-event/arch-support.txt   |  5 +-
 .../features/perf/perf-regs/arch-support.txt   |  3 +-
 .../features/perf/perf-stackdump/arch-support.txt  |  3 +-
 .../sched/membarrier-sync-core/arch-support.txt|  1 +
 .../features/sched/numa-balancing/arch-support.txt |  5 +-
 Documentation/features/scripts/features-refresh.sh | 55 ++
 .../seccomp/seccomp-filter/arch-support.txt|  5 +-
 .../time/arch-tick-broadcast/arch-support.txt  |  3 +-
 .../features/time/clockevents/arch-support.txt |  3 +-
 .../time/context-tracking/arch-support.txt |  1 +
 .../features/time/irq-time-acct/arch-support.txt   |  3 +-
 .../time/modern-timekeeping/arch-support.txt   |  1 +
 .../features/time/virt-cpuacct/arch-support.txt|  1 +
 .../features/vm/ELF-ASLR/arch-support.txt  |  3 +-
 .../features/vm/PG_uncached/arch-support.txt   |  1 +