Re: [PATCH RFC 4/5] rculist: Remove hlist_for_each_entry_rcu_notrace since no users

[Miguel Ojeda]

On Sat, May 25, 2019 at 1:50 AM Joel Fernandes (Google)
 wrote:
>
> The series removes all users of the API and with this patch, the API
> itself.
>
> Signed-off-by: Joel Fernandes (Google) 
> ---
>  .clang-format   |  1 -

Ack for clang-format, and thanks for removing it there too! :-)

Cheers,
Miguel

Re: [PATCH v5 00/15] Compiler Attributes

[Miguel Ojeda]

Hi Sedat,

On Mon, Sep 24, 2018 at 10:46 AM Sedat Dilek  wrote:
>
> [ Please CC me I am not subcribed to this ML ]
>
> Quote from :
>
> Tested-by: Sedat Dilek  (against Linux
> v4.19-rc5 and built with LLVM/Clang v7)

Thanks a lot for testing! Which configuration roughly (e.g.
allmodconfig)? Did you boot it & run it for a while?

Cheers,
Miguel

Re: [PATCH v5 00/15] Compiler Attributes

[Miguel Ojeda]

On Sat, Oct 6, 2018 at 9:13 AM Sedat Dilek  wrote:
>
> Hi Miguel,
>
> In my testoings I am booting in QEMU and on bare metal.
> Both tests were successful.

Wow! I only wanted to confirm it booted and/or run for a while -- but
having more information is always good. Thanks a *lot*!

I will add a reference to your email in the commits.

Cheers,
Miguel

[GIT PULL] Compiler Attributes for v4.20-rc1

[Miguel Ojeda]

Hi Linus,

Here it is the Compiler Attributes series/tree, which tries to disentangle
the include/linux/compiler*.h headers and bring them up to date.

The patches have been in linux-next for a while, *except* the last two
from Nick which came a bit later. Since AFAIU there will be no linux-next
this week, I included them here; but let me know if you prefer
to take them out.

You may see merge conflicts from a few other trees, from what we have
seen in linux-next.

I am not sure if you followed this, so please let me know if there is
anything you don't agree with.

And welcome back!

Cheers,
Miguel

The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:

  Linux 4.19-rc6 (2018-09-30 07:15:35 -0700)

are available in the Git repository at:

  https://github.com/ojeda/linux.git tags/compiler-attributes-for-linus-4.20-rc1

for you to fetch changes up to 1ff2fea5e30ca15752777441ecb64a169fe22e9e:

  compiler-gcc: remove comment about gcc 4.5 from unreachable() (2018-10-19 
08:47:30 +0200)


The Compiler Attributes series

This is an effort to disentangle the include/linux/compiler*.h headers
and bring them up to date.

The main idea behind the series is to use feature checking macros
(i.e. __has_attribute) instead of compiler version checks (e.g. GCC_VERSION),
which are compiler-agnostic (so they can be shared, reducing the size
of compiler-specific headers) and version-agnostic.

Other related improvements have been performed in the headers as well,
which on top of the use of __has_attribute it has amounted to a significant
simplification of these headers (e.g. GCC_VERSION is now only guarding
a few non-attribute macros).

This series should also help the efforts to support compiling the kernel
with clang and icc. A fair amount of documentation and comments have also
been added, clarified or removed; and the headers are now more readable,
which should help kernel developers in general.

The series was triggered due to the move to gcc >= 4.6. In turn, this series
has also triggered Sparse to gain the ability to recognize __has_attribute
on its own.

Finally, the __nonstring variable attribute series has been also applied
on top; plus two related patches from Nick Desaulniers for unreachable()
that came a bit afterwards.

----
Miguel Ojeda (15):
  Compiler Attributes: remove unused attributes
  Compiler Attributes: always use the extra-underscores syntax
  Compiler Attributes: remove unneeded tests
  Compiler Attributes: homogenize __must_be_array
  Compiler Attributes: remove unneeded sparse (__CHECKER__) tests
  Compiler Attributes: add missing SPDX ID in compiler_types.h
  Compiler Attributes: use feature checks instead of version checks
  Compiler Attributes: KENTRY used twice the "used" attribute
  Compiler Attributes: remove uses of __attribute__ from compiler.h
  Compiler Attributes: add Doc/process/programming-language.rst
  Compiler Attributes: add MAINTAINERS entry
  Compiler Attributes: add support for __nonstring (gcc >= 8)
  Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8)
  Compiler Attributes: auxdisplay: panel: use __nonstring
  Compiler Attributes: ext4: remove local __nonstring definition

ndesaulni...@google.com (2):
  compiler.h: update definition of unreachable()
  compiler-gcc: remove comment about gcc 4.5 from unreachable()

 Documentation/process/index.rst|   1 +
 Documentation/process/programming-language.rst |  45 +
 MAINTAINERS|   5 +
 drivers/auxdisplay/panel.c |   7 +-
 fs/ext4/ext4.h |   9 -
 include/linux/compiler-clang.h |   5 -
 include/linux/compiler-gcc.h   |  74 +--
 include/linux/compiler-intel.h |   9 -
 include/linux/compiler.h   |  24 +--
 include/linux/compiler_attributes.h| 258 +
 include/linux/compiler_types.h | 101 ++
 scripts/Makefile.extrawarn |   1 +
 12 files changed, 345 insertions(+), 194 deletions(-)
 create mode 100644 Documentation/process/programming-language.rst
 create mode 100644 include/linux/compiler_attributes.h

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Miguel Ojeda]

On Thu, Nov 1, 2018 at 6:06 PM Linus Torvalds
 wrote:
>
> I'm not sure how much that matters (maybe the original check for 4.9.2
> was just a random pick by Andrey? Added to cc), but together with the
> movement to  that looks like it also
> wouldn't want the CONFIG_KASAN tests, I wonder what the right merge
> resolution would be.

Good catch. I don't recall any special logic when I did that change,
so most likely I simply did like for the rest of the attributes and
took a look at when it was first supported (and documentation in gcc's
docs) in order to implement __has_attribute by hand.

But indeed, it *may* be that there is an (undocumented) problem
between 4.8 <= gcc < 4.9.2 with it. If so, we should document it down
and fix it. Andrey?

> Yes, I see the resolution in linux-next, and I think that one is odd
> and dubious, and now it *mixes* that old test of gcc-4.9.2 with the
> different test in compiler-attributes.

I missed that conflict completely, my bad (I did not miss all of them,
at least; one required fixing).

Hm at a quick look, why is it only on compiler-gcc.h? It should
either have a corresponding #define elsewhere or just be put directly
in another common header, no? (Adding Vasily & Martin to CC.)

> But I'm also unsure whether you meant for the "__has_attribute()" test
> to be usable outside the linux/compiler_attributes.h file, in which
> case I could just do
>
>   #if defined(CONFIG_KASAN) && __has_attribute(__no_sanitize_address__)
>
> instead.

I think that (using __has_attribute() outside) may be a good idea: I
wanted to keep compiler_attributes.h as simple as possible by avoiding
#ifdefs inside that header (except for __has_attribute itself), as an
attempt to avoid going back to the mess of #ifdefs we had previously.
Basically, keeping the attributes in compiler_attributes.h that do not
depend on complex logic. So using __has_attribute *outside* the header
actually goes well with that principle, because it helps keeping stuff
out of it if they depend on other config options; without having to
rely on GCC_VERSION either.

[By the way, in case it clarifies: note that "optional" in that file
actually is a bit of a misnomer. I meant to say "optional" as in "not
supported by all compilers, so conditionally defined" ("optionally"
defined); rather than "optional" in the sense of "code still works
without the attribute". It caught Rasmus in one of his patches sent a
few days ago on top of this tree, so I want to change it or explain it
to avoid confusion.]

Cheers,
Miguel

Re: [GIT PULL] Compiler Attributes for v4.20-rc1

[Miguel Ojeda]

On Fri, Nov 2, 2018 at 2:52 AM Linus Torvalds
 wrote:
>
> Anyway, I decided to do the merge by just getting rid of the
> GCC_VERSION check around __no_sanitize_address_or_inline entirely. If
> you enable KASAN, then a function with that marking just won't be
> marked inline.

I was a bit confused when reading the gcc bug reports, i.e. why gcc
did *not* complain in 4.9 but it did in 5.1 (when it was supposed to
complain also in 4.9). It turns out that gcc 5.1 takes into account
who is the actual caller due to this change:

+  cgraph_node *caller = e->caller->global.inlined_to
+   ? e->caller->global.inlined_to : e->caller;
...
-  else if (!sanitize_attrs_match_for_inline_p (e->caller->decl, callee->decl))
+  else if (!sanitize_attrs_match_for_inline_p (caller->decl, callee->decl))

change; e.g. this:

#define really_inline inline __attribute__((always_inline))
#define no_sanitize __attribute__((no_sanitize_address))

really_inline void f() {}
really_inline void g() { f(); }
no_sanitize void h() { g(); }

Complains in gcc 4.9 -O0, 5.1 -O0 and 5.1 -O2; but *not* in 4.9 -O2.
https://godbolt.org/z/kNApqk

Anyway, this is orthogonal but in case it clarifies that for someone else...

> Miguel, please do double-check the merge (it's not pushed out yet, I'm
> doing the usual build tests etc first).

I was sleeping, didn't manage to see it (in your GitHub, I guess?).

I did the merge myself, and arrived at the same thing as you. I
quickly inspected the rest and seems fine. By the way, I spotted an
extra space at:

+ * we do one or the other.

Cheers,
Miguel

Re: [PATCH v5 00/15] Compiler Attributes

[Miguel Ojeda]

On Mon, Sep 24, 2018 at 4:36 PM Luc Van Oostenryck
 wrote:
>
> On Thu, Sep 20, 2018 at 07:22:46PM +0200, Miguel Ojeda wrote:
> > The Compiler Attributes series is an effort to disentangle
> > the include/linux/compiler*.h headers and bring them up to date.
> >
> > The main idea behind the series is to use feature checking macros
> > (i.e. __has_attribute) instead of compiler version checks (e.g. 
> > GCC_VERSION),
> > which are compiler-agnostic (so they can be shared, reducing the size
> > of compiler-specific headers) and version-agnostic.
> >
> > Other related improvements have been performed in the headers as well,
> > which on top of the use of __has_attribute it has amounted to a significant
> > simplification of these headers (e.g. GCC_VERSION is now only guarding 4
> > non-attribute macros).
> >
> > This series should also help the efforts to support compiling the kernel
> > with clang and icc. A fair amount of documentation and comments have also
> > been added, clarified or removed; and the headers are now more readable,
> > which should help kernel developers in general.
> >
> > The series was triggered due to the move to gcc >= 4.6. In turn, this series
> > has also triggered Sparse to gain the ability to recognize __has_attribute
> > on its own.
> >
> > Finally, the nonstring variable attribute series has been applied on top
> > of this one.
>
> Hi Miguel,
> Feel free to add my
>   Reviewed-by: Luc Van Oostenryck 
> on patches 11-15 (I think the others ones already have it).
>

Done for both Nick and you!

Cheers,
Miguel

Re: [PATCH v5 12/15] Compiler Attributes: add support for __nonstring (gcc >= 8)

[Miguel Ojeda]

On Thu, Sep 20, 2018 at 10:08 PM Kees Cook  wrote:
>
> Reviewed-by: Kees Cook 
>

Done! Thanks!

Cheers,
Miguel

Re: [PATCH v5 13/15] Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8)

[Miguel Ojeda]

On Thu, Sep 20, 2018 at 9:56 PM Kees Cook  wrote:
>
> Ye. :)
>
> Reviewed-by: Kees Cook 

Done! Thanks! :)

Cheers,
Miguel

[GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

Hi Stephen,

The Compiler Attributes series has been stable for 10+ days. To
increase testing before 4.20, I would to request it being picked up
for -next.

The changes w.r.t. v5 in the LKML:

  - Rebased on top of next-20180928, which required removing
aligned_largest, which was removed by 9503cd9cbaba
("include/linux/compiler*.h: add version detection to
asm_volatile_goto").
  - Added latest Reviewed-by's and Tested-by's.

Thanks!

Cheers,
Miguel

The following changes since commit 4794a36bf08dfa89fe636e5080db9d8350e255dd:

  Add linux-next specific files for 20180928 (2018-09-28 15:26:51 +1000)

are available in the Git repository at:

  https://github.com/ojeda/linux.git compiler-attributes

for you to fetch changes up to dbce062c0b519db1cdad8d87ab46851f0be6bdea:

  Compiler Attributes: ext4: remove local __nonstring definition
(2018-10-02 15:11:26 +0200)

--------
Miguel Ojeda (15):
  Compiler Attributes: remove unused attributes
  Compiler Attributes: always use the extra-underscores syntax
  Compiler Attributes: remove unneeded tests
  Compiler Attributes: homogenize __must_be_array
  Compiler Attributes: remove unneeded sparse (__CHECKER__) tests
  Compiler Attributes: add missing SPDX ID in compiler_types.h
  Compiler Attributes: use feature checks instead of version checks
  Compiler Attributes: KENTRY used twice the "used" attribute
  Compiler Attributes: remove uses of __attribute__ from compiler.h
  Compiler Attributes: add Doc/process/programming-language.rst
  Compiler Attributes: add MAINTAINERS entry
  Compiler Attributes: add support for __nonstring (gcc >= 8)
  Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8)
  Compiler Attributes: auxdisplay: panel: use __nonstring
  Compiler Attributes: ext4: remove local __nonstring definition

 Documentation/process/index.rst|   1 +
 Documentation/process/programming-language.rst |  45 +
 MAINTAINERS|   5 +
 drivers/auxdisplay/panel.c |   7 +-
 fs/ext4/ext4.h |   9 -
 include/linux/compiler-clang.h |   5 -
 include/linux/compiler-gcc.h   |  70 +--
 include/linux/compiler-intel.h |   9 -
 include/linux/compiler.h   |  19 +-
 include/linux/compiler_attributes.h| 257 +
 include/linux/compiler_types.h | 100 ++
 scripts/Makefile.extrawarn |   1 +
 12 files changed, 340 insertions(+), 188 deletions(-)
 create mode 100644 Documentation/process/programming-language.rst
 create mode 100644 include/linux/compiler_attributes.h

Re: [GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

Hi Stephen,

On Tue, Oct 2, 2018 at 11:11 PM Stephen Rothwell  wrote:
>
> Hi Miguel,
>
> On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda 
>  wrote:
> >
> > The Compiler Attributes series has been stable for 10+ days. To
> > increase testing before 4.20, I would to request it being picked up
> > for -next.
> >
> > The changes w.r.t. v5 in the LKML:
> >
> >   - Rebased on top of next-20180928, which required removing
>
> Unfortunately, trees/branches included in linux-next must be based on
> something stable (usually Linus' tree, but it could be another
> tree/branch that is included in linux-next that does not rebase).
> Linux-next itself rebases every day, so snything based on it would drag
> in a previous version of all the other trees :-(

I assumed you could apply changes as a diff/patches/cherry-pick, not
as a merge, for those that went on top of others (so that at the new
merge window, conflicts were already solved). Otherwise, why are
next-* tags/branches provided anyway?

>
> > aligned_largest, which was removed by 9503cd9cbaba
> > ("include/linux/compiler*.h: add version detection to
> > asm_volatile_goto").
>
> That commit is from Andrew's patch series which also rebases (usually
> at least every week), so you cannot depend on it.

Then who is solving the conflict?

Thanks!

Cheers,
Miguel

Re: [GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

Hi Nick,

On Tue, Oct 2, 2018 at 11:16 PM Nick Desaulniers
 wrote:
>
> On Tue, Oct 2, 2018 at 2:11 PM Stephen Rothwell  wrote:
> >
> > Hi Miguel,
> >
> > On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda 
> >  wrote:
> > >
> > > The Compiler Attributes series has been stable for 10+ days. To
> > > increase testing before 4.20, I would to request it being picked up
> > > for -next.
> > >
> > > The changes w.r.t. v5 in the LKML:
> > >
> > >   - Rebased on top of next-20180928, which required removing
> >
> > Unfortunately, trees/branches included in linux-next must be based on
> > something stable (usually Linus' tree, but it could be another
> > tree/branch that is included in linux-next that does not rebase).
> > Linux-next itself rebases every day, so snything based on it would drag
> > in a previous version of all the other trees :-(
>
> I think of this like a branch that's force pushed to.  Can't base
> other branches or trees off of it cause it's always moving/force
> rewriting history.

As I have read, -next is supposed to be a vision of what the merge
window will look like after merging everything, i.e. ideally -rc1. For
that to work for files out-of-tree (like these ones, which are not
maintained by a single tree), changes should be allowed to be stacked
on each other; otherwise, we cannot handle conflicts :-(

>
> >
> > > aligned_largest, which was removed by 9503cd9cbaba
> > > ("include/linux/compiler*.h: add version detection to
> > > asm_volatile_goto").
> >
> > That commit is from Andrew's patch series which also rebases (usually
> > at least every week), so you cannot depend on it.
>
> Miguel, you should be able to drop that patch from your set then,
> since Andrew's -mm tree flows into this -next tree as well, IIUC.
> We'll take up that patch from there.

Not sure what you mean by "drop that patch". There is no patch to
drop, there is a conflict with a change already in -next.

Cheers,
Miguel

Re: [GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

Hi Ted,

On Wed, Oct 3, 2018 at 1:25 AM Theodore Y. Ts'o  wrote:
>
> On Wed, Oct 03, 2018 at 12:12:10AM +0200, Miguel Ojeda wrote:
> > As I have read, -next is supposed to be a vision of what the merge
> > window will look like after merging everything, i.e. ideally -rc1. For
> > that to work for files out-of-tree (like these ones, which are not
> > maintained by a single tree), changes should be allowed to be stacked
> > on each other; otherwise, we cannot handle conflicts :-(
>
> In general, best practice is to base tree on an -rcX commit.  I
> usually will use something like -rc4 which is after most of the major
> changes have gone in.  This tends to reduce conflicts for most git
> trees.

Sure. That is what I do for mainline PRs to Linus. As you say, it
works fine for mostly independent trees. But it doesn't (that well)
for out-of-tree stuff or for stuff spanning several trees.

>
> There are times when a commit in one tree needs to depend on a commit
> in another tree.  What to do depends on the circumstances.
>

Exactly. And for this case, I simply assumed Stephen wanted a clean
series to apply on top of the latest next-* tag (same way we base
stuff on top of -rc*s). Note that this is *not* really a "tree"
collecting changes/development, it is a patch series, i.e. what is
important is only the range-diff.

What has surprised me is that -next does not allow for range-diffs
(patches/commits/...) to be inside -next, maybe applied after all the
normal merges of trees. I simply assumed it did, given what I could
find about -next (which does not seem to be documented properly, by
the way).

>
> So another solution is to simply evade the problem.  If the reason why
> tree A needs to depend on tree B is that tree B is using some
> interface which has changed, if it's a minor change, then Stephen will
> fix it up when he pulls the changes; just as Linus will.

While this is a simple conflict, I don't really agree with release
maintainers having to fix conflicts on the fly (even if it is a single
trivial line), but that is an orthogonal discussion...

> Yet another solution is to arrange the code changes to avoid needing
> commits that might conflict.  For example, in fs/ext4/ext4.h, I very
> deliberately did this.
>
> /* Until this gets included into linux/compiler-gcc.h */
> #ifndef __nonstring
> #if defined(GCC_VERSION) && (GCC_VERSION >= 8)
> #define __nonstring __attribute__((nonstring))
> #else
> #define __nonstring
> #endif
> #endif
>
> You included a cleanup patch to remove it in your git tree, but it
> wasn't actually necessary.  If there was a merge conflict, it would be
> simple enough to just drop your cleanup patch, since I had carefully
> used #ifndef __nonstring... #endif.  So the idea was that if someone
> defined __nonstring somewhere else, it wouldn't break the build with a
> duplicate #define since it was protected with an #ifndef.
>
> I didn't mind that you included a cleanup patch; but I set things up
> so that it would not be necessary, since often the best way to solve a
> merge conflict is by avoiding the need for the change (in some other
> git tree) in the first place.  :-)

Alright, I am not sure how to answer this without sounding
"aggressive" and maybe I misunderstood something you tried to point
out, so I apologize in advance. There are several points here:

  * The merge conflict isn't related to this (but let's assume it was,
since you pointed this out as an example -- I guess; although I am not
sure why).

  * Thanks for explaining, but I think most people here understand how
#ifndef works :-) Also note that we already had guards for some
attributes that needed per-compiler implementations.

  * The patch is actually necessary:

- Several people argued that examples should be present when I
introduced __nonstring earlier in the series. While I don't think they
are mandatory for this case, they are good to have, and since they
were anyway requested, I happily added them.

- Changes should include everything related to them (as far as
possible, i.e. extreme examples aside). Adding __nonstring and not
removing the ext4 part would simply be leaving undone work (which has
to be done sooner or later). To be honest, it could have even been
done in the same commit and I would say it is logically OK (even if
not great).

- Related to that: I think the outer #ifndef shouldn't have been
included to begin with, because it is either wrong or dead code: if we
end up having a __nonstring, it should be removed at the same time
(like this series does); and if __nonstring isn't there (like now), it
isn't guarding against anything. At worst, it could hide a mismatch in
the definitions.

- I promised to you I would clean it up :-)

You seem to argue that it is better to avoid merge conflicts rather
than doing a proper series. Well, I think we should really try to
avoid conflicts pushing down the """quality""" of
patches/commits/series.

Cheers,
Miguel

Re: [GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

HI Dominique,

On Wed, Oct 3, 2018 at 12:37 AM Dominique Martinet
 wrote:
>
> Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > As I have read, -next is supposed to be a vision of what the merge
> > window will look like after merging everything, i.e. ideally -rc1. For
> > that to work for files out-of-tree (like these ones, which are not
> > maintained by a single tree), changes should be allowed to be stacked
> > on each other; otherwise, we cannot handle conflicts :-(
>
> The rule is the same as with a regular mainline pull; I don't have the
> reference at hand but in some recent-ish pull request Linus said he

That is actually the first problem: there is no
reference/documentation at hand. :-P

Cheers,
Miguel

Re: [GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

Hi Stephen,

On Wed, Oct 3, 2018 at 1:00 AM Stephen Rothwell  wrote:
>
> Hi Miguel,
>
> On Wed, 3 Oct 2018 00:36:52 +0200 Dominique Martinet  
> wrote:
> >
> > Miguel Ojeda wrote on Wed, Oct 03, 2018:
> > > As I have read, -next is supposed to be a vision of what the merge
> > > window will look like after merging everything, i.e. ideally -rc1. For
> > > that to work for files out-of-tree (like these ones, which are not
> > > maintained by a single tree), changes should be allowed to be stacked
> > > on each other; otherwise, we cannot handle conflicts :-(
> >
> > The rule is the same as with a regular mainline pull; I don't have the
> > reference at hand but in some recent-ish pull request Linus said he
> > prefers the stable version with the conflict, and optionally you can
> > provide a second branch with the conflict resolved for reference, but
> > the pull request should be based on something stable even if it has
> > conflicts
> >
> > If there is a conflict Stefen will resolve it like Linus/Greg would, and
> > the resolved bit will be carried over everyday so it's not much more
> > work -- exactly like a regular pull request for inclusion in the main
> > tree :)
>
> Exactly what Dominique said.  I will fix up the conflict (unless it is
> a very complex conflict, in which case the author(s) should help) and
> the Linus (or Greg) will do the same.  If you do depend on a patch in
> Andrew's series, what happens if that patch does not get sent to Linus
> during the merge window or Linus rejects it?

This doesn't depend on anything. Not sure what is all the fuss about
-- people got confused into thinking we had to drop a patch for some
reason. As explained in the first email, I simply rebased v5 (which is
based on top of rcX) to resolve the conflict myself (i.e. it does
*not* depend on changes in -next). If you are the one solving
conflicts yourself (which is what I asked in my second email), there
is no problem to begin with; I will simply send v6 to you and we are
done.

When I sent the first email, I assumed that changes in -next were
supposed to be clean -- my mistake, but please document somewhere how
-next works! Specially that you are rerere'ing conflicts and
re-resolving them every day.

Then the discussion shifted to what to do with changes that actually
depend on other changes.

Cheers,
Miguel

Re: [GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

Hi Ted,

On Wed, Oct 3, 2018 at 5:33 PM Theodore Y. Ts'o  wrote:
>
> On Wed, Oct 03, 2018 at 01:54:05PM +0200, Miguel Ojeda wrote:
> >
> > Exactly. And for this case, I simply assumed Stephen wanted a clean
> > series to apply on top of the latest next-* tag (same way we base
> > stuff on top of -rc*s). Note that this is *not* really a "tree"
> > collecting changes/development, it is a patch series, i.e. what is
> > important is only the range-diff.
> >
> > What has surprised me is that -next does not allow for range-diffs
> > (patches/commits/...) to be inside -next, maybe applied after all the
> > normal merges of trees. I simply assumed it did, given what I could
> > find about -next (which does not seem to be documented properly, by
> > the way).
>
> Part of the reason why I wrote my long message was because the -next
> tree usage has been mostly by convention.  Better documentation would
> be a good thing; I think the main reason why we don't have it is that
> historically, the people who submit direct pull requests to Linus
> already know how things work.  Obviously that's not a great
> assumption, but in fact there are a large number of things about what
> is needed to be a subsystem maintainer which needs to be documented,
> and the linux-next tree is just one part of it.  (And perhaps not even
> the biggest part.)

It not a bad assumption either -- I happen to be one a very odd
maintainer because I have not been actively contributing for years so
I missed the -next implementation, so it is fine, I don't blame anyone
for my mistake; still a few lines would be fine: who is the
maintainer, where to send the patches, who should be Cc'd, etc. :-)

>
> Historically there was one source of changes into the linux-next tree
> which was done as quilt-style patch series, and that was Andrew
> Morton's mmotm tree.  Part of the problem is that it's a lot more work
> to consume a patch series, and so these days while Andrew still uses a
> patch series, he exports a git tree[1] which is what I believe Stephen
> and Linus use.  (For that matter, I use a patch series[2] as well, but
> the public interface is the ext4.git tree on git.kernel.org.)

Hm... I agree that patches (i.e. referring to the email workflow) are
a pain, but I am not sure why the actual "patches" (i.e. referring to
the commits/diffs) need to be harder to work with. Maybe we don't have
the tools for that yet. For instance, the new git range-diff command
is actually quite good to compare versions of series after rebasing.

>
> [1] https://www.ozlabs.org/~akpm/mmotm/mmotm-readme.txt
> [2] https://ext4.wiki.kernel.org/index.php/Ext4_patchsets
>
> > While this is a simple conflict, I don't really agree with release
> > maintainers having to fix conflicts on the fly (even if it is a single
> > trivial line), but that is an orthogonal discussion...
>
> Sure; there are some srtong reasons for it, but we can save that for
> the Maintainer's Handbook discussion.  I will say that this is
> something where attempts to avoid Linus needing to fix conflicts on
> the fly, such as a rebase right before a PULL request, violates
> Linus's rules which has in the past resulted in him expressing a
> "strong" correction e-mail to Maintainers since it was assumed that
> they really should have known better.  Linus has said he doesn't want
> to yell at Maintainers, so we can support him by getting the
> Maintainer's Handbook out there.  :-)

Yeah, I actually got the correction myself :-) I understand Linus'
reasons about the benefits of using the merges (and I agree that
information shouldn't be dropped); but I think there has to be a
better way to handle conflicts. (See below).

>
> > Alright, I am not sure how to answer this without sounding
> > "aggressive" and maybe I misunderstood something you tried to point
> > out, so I apologize in advance. There are several points here:
> >
> >   * The merge conflict isn't related to this (but let's assume it was,
> > since you pointed this out as an example -- I guess; although I am not
> > sure why).
>
> I thought I was clear that I used it as an example, but my apologies
> if that didn't come across.

No apologies needed!

>
> > - Changes should include everything related to them (as far as
> > possible, i.e. extreme examples aside). Adding __nonstring and not
> > removing the ext4 part would simply be leaving undone work (which has
> > to be done sooner or later). To be honest, it could have even been
> > done in the same commit and I would say it is logically OK (even if
> > not great).
> > ...
> &g

Re: [GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

On Wed, Oct 3, 2018 at 11:23 PM Miguel Ojeda
 wrote:
> On Wed, Oct 3, 2018 at 5:33 PM Theodore Y. Ts'o  wrote:
> > had done with full consideration, specifically for this reason.  Even
> > if the definition was different, my definition *had* been fully tested
> > with over a 27+ VM hours of regression testing, and if it turned out

I forgot to mention that if the definitions were different, it could
have caused a problem, because your definition wouldn't apply, so your
27+ hours of testing wouldn't have mattered :-P Without the #ifndef,
we would have at least got a redefinition warning about it.

Cheers,
Miguel

Re: [GIT PULL linux-next] Add Compiler Attributes tree

[Miguel Ojeda]

Hi Ted,

On Thu, Oct 4, 2018 at 7:02 AM Theodore Y. Ts'o  wrote:
> In this case, yes.  Again, I emphasize that I was using the ext4.h
> cleanup as an *example*.  The point I was trying to make was that your
> change did *not* do a full set of deep ext4 regression tests because
> the your change didn't go through the ext4.git tree.  I have seen

Because it shouldn't matter from which tree they come from to get the
tests run. *That* is the problem: effectively we have independent
projects in the kernel. If you tell me that my change did not run the
ext4 tests (even if I Cc'd you or maybe some ML, etc.), it means there
is something wrong.

> cases where "simple mechanical changes" were anything but, and while
> the kernel *compiled* it resulted in the file system not working.
> (And in the worst case, it resulted actual data loss or file system
> corruption.)

Yes, I have also experienced one-liners breaking entire projects.
Ideally, any change should be assumed to break everything unless
proved otherwise, and I agree with having as much testing as possible
-- see above for the actual problem here.

> My test scripts are public, and in fact I've gone out of my way to
> make them easy for other people to run them, with documentation[1][2],
> slide sets[3], etc.  But the vast majority of people who submit
> patches to ext4.git don't bother --- and as far as I know *no one* who
> sends ext4 changes via other git trees *ever* bothered.  (And, for one
> recent patchset where the ext4 developer spent a lot of time using
> kvm-xfstests before submission, accepting that set of changes was easy
> and was a joy.  I'm a big believe in tests.)

I believe you -- but actually I would *expect* that. Nobody runs them
because nobody has either the time, the expertise, or feels the need
to do so. It is not a matter of "being easy to run". It is simply that
people won't do it unless you force them to (and if you force them,
you will lose some contributions).

The solution is not providing slides, documentation, or making it
fool-proof. The solution, in my view, is avoiding people having to do
the tests. Currently, I thought we do that in the kernel by Cc'ing
whoever is a maintainer of the code and letting that person do
whatever is required for those changes. Of course, you can automate
this in many fancy ways as many projects/companies have done (and as
you describe for Google).

However...

> So if you are willing to completely standardize your testing
> infrastructure and devote utterly lavish amounts of automated testing

...I don't agree. I don't think this follows from the above
discussion. While release management and testing are topics that go
together (pretty much always), they are two different, independent
problems. I am talking here about the need for some "software" to do
the release management (i.e. merging many trees, doing integration,
etc.), not the testing side of it (which can change irrespective of
the release management side; e.g. may have different triggers, may
have different requirements, may use different systems to help, etc.).

Actually, it is fairly easy to prove: Pick Documentation/ and imagine
it was only plain text files without processing required (as in the
old days). For that "project", you don't need any testing whatsoever,
but you still need to do release integration. For ext4, you may want
to use your testing scripts. For drivers/foo/bar.c, maybe the only way
of testing is plugging the hardware and seeing that it works. So,
different projects, different testing mechanisms; but same release
integration at the end of the day.

> which is deeply integrated into a standardized, non-email code review
> system, the challenge you have identified *has* been solved.  But

Of course it has been "solved". All projects with hundreds of
contributors/subprojects/... have to deal with the same issues, and
they have to keep moving forward at the end of the day. The point is
not how Google, or CERN, or anybody else does it. The point is that
there should be a better way to handle this which makes kernel
development better.

I explained the issue we faced at CERN years ago simply because it was
very similar to this (merging given tags of different trees,
basically). I am not sure how/if your Google example is relevant here,
since it is a completely custom system, it is very different to what
the kernel does, etc. I understand you are trying to say "this is no
news, there are other ways of solving it, it is solved at Google"; but
with my "example" I was not trying to say "we solved it at CERN" or
trying to say I am a "guru"; I was simply stating that it seems there
could be a project coming out of this to solve this space *in the
context of the kernel workflow*.

> trust me when I say that it is a very non-trivial thing to do, and it
> requires a lot of very strict code development practices that are
> imposed on all Google C++ developers working in the common tree (which
> is probably 90%+ of the SWE's inside

[GIT PULL linux-next] Add Compiler Attributes (v6) tree

[Miguel Ojeda]

Hi Stephen,

As discussed, here it is the Compiler Attributes series for
linux-next. This time the original v6, based on -rc6.

The changes w.r.t. v5:

  - Added latest Reviewed-by's and Tested-by's.

The conflicts are trivial to solve, but if you want a reference, take
a look at (rebased on top of next-20181005):

  https://github.com/ojeda/linux.git compiler-attributes-rebased

Thanks!

Cheers,
Miguel

The following changes since commit 17b57b1883c1285f3d0dc2266e8f79286a7bef38:

  Linux 4.19-rc6 (2018-09-30 07:15:35 -0700)

are available in the Git repository at:

  https://github.com/ojeda/linux.git compiler-attributes

for you to fetch changes up to f0604f63033d4020f019d2aaee805c1075b1077b:

  Compiler Attributes: ext4: remove local __nonstring definition
(2018-09-30 20:14:04 +0200)

--------
Miguel Ojeda (15):
  Compiler Attributes: remove unused attributes
  Compiler Attributes: always use the extra-underscores syntax
  Compiler Attributes: remove unneeded tests
  Compiler Attributes: homogenize __must_be_array
  Compiler Attributes: remove unneeded sparse (__CHECKER__) tests
  Compiler Attributes: add missing SPDX ID in compiler_types.h
  Compiler Attributes: use feature checks instead of version checks
  Compiler Attributes: KENTRY used twice the "used" attribute
  Compiler Attributes: remove uses of __attribute__ from compiler.h
  Compiler Attributes: add Doc/process/programming-language.rst
  Compiler Attributes: add MAINTAINERS entry
  Compiler Attributes: add support for __nonstring (gcc >= 8)
  Compiler Attributes: enable -Wstringop-truncation on W=1 (gcc >= 8)
  Compiler Attributes: auxdisplay: panel: use __nonstring
  Compiler Attributes: ext4: remove local __nonstring definition

 Documentation/process/index.rst|   1 +
 Documentation/process/programming-language.rst |  45 +
 MAINTAINERS|   5 +
 drivers/auxdisplay/panel.c |   7 +-
 fs/ext4/ext4.h |   9 -
 include/linux/compiler-clang.h |   5 -
 include/linux/compiler-gcc.h   |  70 +--
 include/linux/compiler-intel.h |   9 -
 include/linux/compiler.h   |  19 +-
 include/linux/compiler_attributes.h| 258 +
 include/linux/compiler_types.h | 101 ++
 scripts/Makefile.extrawarn |   1 +
 12 files changed, 341 insertions(+), 189 deletions(-)
 create mode 100644 Documentation/process/programming-language.rst
 create mode 100644 include/linux/compiler_attributes.h

Re: [PATCH] docs: Introduce deprecated APIs list

[Miguel Ojeda]

On Wed, Oct 17, 2018 at 4:20 AM Kees Cook  wrote:
>
> As discussed in the "API replacement/deprecation" thread[1], this
> makes an effort to document what things shouldn't get (re)added to the
> kernel, by introducing Documentation/process/deprecated.rst. It also
> adds the overflow kerndoc to ReST output, and tweaks the struct_size()
> documentation to parse correctly.

If you remember, please CC me as well, since I would like to be
involved in this as well, given that  it touches the compiler
attributes :-)

Also, I will send a patch (for the deprecated.rst file, adding a
section about fallthrough comments) later on.

Thanks for adding the file!

Cheers,
Miguel

[PATCH 2/2] Compiler Attributes: auxdisplay: panel: use __fallthrough

[Miguel Ojeda]

Let gcc know these cases are meant to fall through to the next label
by annotating them with the new __fallthrough statement attribute;
and remove the comment since it conveys the same information
(which was also parsed by gcc to suppress the warning).

Signed-off-by: Miguel Ojeda 
---
 drivers/auxdisplay/panel.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/auxdisplay/panel.c b/drivers/auxdisplay/panel.c
index 21b9b2f2470a..0755034e49ba 100644
--- a/drivers/auxdisplay/panel.c
+++ b/drivers/auxdisplay/panel.c
@@ -1367,7 +1367,7 @@ static void panel_process_inputs(void)
break;
input->rise_timer = 0;
input->state = INPUT_ST_RISING;
-   /* fall through */
+   __fallthrough;
case INPUT_ST_RISING:
if ((phys_curr & input->mask) != input->value) {
input->state = INPUT_ST_LOW;
@@ -1380,11 +1380,11 @@ static void panel_process_inputs(void)
}
input->high_timer = 0;
input->state = INPUT_ST_HIGH;
-   /* fall through */
+   __fallthrough;
case INPUT_ST_HIGH:
if (input_state_high(input))
break;
-   /* fall through */
+   __fallthrough;
case INPUT_ST_FALLING:
input_state_falling(input);
}
-- 
2.17.1

[PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

>From the GCC manual:

  fallthrough

The fallthrough attribute with a null statement serves as a
fallthrough statement. It hints to the compiler that a statement
that falls through to another case label, or user-defined label
in a switch statement is intentional and thus the -Wimplicit-fallthrough
warning must not trigger. The fallthrough attribute may appear
at most once in each attribute list, and may not be mixed with
other attributes. It can only be used in a switch statement
(the compiler will issue an error otherwise), after a preceding
statement and before a logically succeeding case label,
or user-defined label.

  https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html

Currently, most of the kernel uses fallthrough comments to silence
the -Wimplicit-fallthrough warnings (enabled by -Wextra, in W=1).
However, C++17 standarized an "statement attribute" (the first
of its kind) to deal with this: [[fallthrough]] is meant to be
a new control keyword in the form of an extension.

In C mode, GCC supports the __fallthrough__ attribute since 7.1,
the same time the warning and the comment parsing were introduced.

While comment parsing is a good idea to deal with old codebases
that used such a comment as documentation for humans, the best
solution is to use the attribute:

  * It is a "real" part of the AST (=> better for tooling).

  * It does not follow arbitrary rules for parsing (e.g. regexps
for the comment parsing).

  * It may even become standarized in C as well: there are ongoing
proposals to import some C++ standard attributes into
the C standard, e.g. for fallthrough:

  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2268.pdf

On top of that, it is also a better solution for the kernel, because:

  * We can actually use a #define for it like for the rest of
attributes/extensions, which is not possible with a comment,
so that its naming/usage is consistent across the entire kernel.

  * Whenever the migration from the comments to the attribute
is complete, we may increase the level of the GCC warning up to 5,
i.e. comments will not longer be considered for warning
surpression:  only the attribute must be used. This would enforce
consistency by leveraging the compiler directly (instead of
enforcing it with other tools).

  * Further into the future, we can consider moving the warning
up to W=0 or even making it an error.

It is worth noting that clang >= 3.2 supports the warning and
the attribute, but only in C++ mode (and it is not enabled by
-Wall/-Wextra/-Wpedantic like in gcc). Hopefully, they will also
support it for C as well.

Further, icc >= 18 does not seem to know anything about the warning;
except that it accepts (i.e. ignores) [[fallthrough]] in C++17 mode
(to be conformant, probably).

Link: https://lore.kernel.org/lkml/20181017062255.oiu44y4zuuwilan3@mwanda/
Suggested-by: Dan Carpenter 
Signed-off-by: Miguel Ojeda 
---
 include/linux/compiler_attributes.h | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/include/linux/compiler_attributes.h 
b/include/linux/compiler_attributes.h
index 6b28c1b7310c..9e2153f85462 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -32,6 +32,7 @@
 # define __GCC4_has_attribute___assume_aligned__  (__GNUC_MINOR__ >= 9)
 # define __GCC4_has_attribute___designated_init__ 0
 # define __GCC4_has_attribute___externally_visible__  1
+# define __GCC4_has_attribute___fallthrough__ 0
 # define __GCC4_has_attribute___noclone__ 1
 # define __GCC4_has_attribute___optimize__1
 # define __GCC4_has_attribute___nonstring__   0
@@ -133,6 +134,23 @@
 # define __visible
 #endif
 
+/*
+ * Currently, most of the kernel uses fallthrough comments to silence
+ * the -Wimplicit-fallthrough warnings (enabled by -Wextra, in W=1).
+ * For new instances, please use this attribute instead.
+ *
+ * Optional: only supported since gcc >= 7.1
+ * Optional: not supported by clang
+ * Optional: not supported by icc
+ *
+ *   gcc: 
https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#index-fallthrough-statement-attribute
+ */
+#if __has_attribute(__fallthrough__)
+# define __fallthrough  __attribute__((__fallthrough__))
+#else
+# define __fallthrough
+#endif
+
 /*
  *   gcc: 
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-format-function-attribute
  * clang: https://clang.llvm.org/docs/AttributeReference.html#format
-- 
2.17.1

[PATCH 0/2] Compiler Attributes: __fallthrough

[Miguel Ojeda]

These are two patches are meant to go on top of the rest of the compiler
attributes series on:

  https://github.com/ojeda/linux/tree/compiler-attributes

which will be sent to Greg for the next merge window.

Please review them and let me know! (specially if someone is against
__fallthrough for some reason :-).

The first patch introduces the attribute and gives the rationale.
The second patch is an example of usage.

This was started in the following thread:

  https://lore.kernel.org/lkml/20181017062255.oiu44y4zuuwilan3@mwanda/

Cheers,
Miguel

Cc: Dan Carpenter 
Cc: Andreas Dilger 
Cc: Masahiro Yamada 
Cc: Michal Marek 
Cc: Steven Rostedt 
Cc: Mauro Carvalho Chehab 
Cc: Olof Johansson 
Cc: Konstantin Ryabitsev 
Cc: David S. Miller 
Cc: Andrey Ryabinin 
Cc: Kees Cook 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Paul Lawrence 
Cc: Sandipan Das 
Cc: Andrey Konovalov 
Cc: David Woodhouse 
Cc: Will Deacon 
Cc: Philippe Ombredanne 
Cc: Paul Burton 
Cc: David Rientjes 
Cc: Willy Tarreau 
Cc: Martin Sebor 
Cc: Christopher Li 
Cc: Jonathan Corbet 
Cc: Theodore Ts'o 
Cc: Geert Uytterhoeven 
Cc: Rasmus Villemoes 
Cc: Joe Perches 
Cc: Arnd Bergmann 
Cc: Dominique Martinet 
Cc: Stefan Agner 
Cc: Luc Van Oostenryck 
Cc: Nick Desaulniers 
Cc: Andrew Morton 
Cc: Greg Kroah-Hartman 
Cc: Linus Torvalds 
Cc: linux-doc@vger.kernel.org
Cc: linux-e...@vger.kernel.org
Cc: linux-spa...@vger.kernel.org
Cc: linux-kbu...@vger.kernel.org

Miguel Ojeda (2):
  Compiler Attributes: add support for __fallthrough (gcc >= 7.1)
  Compiler Attributes: auxdisplay: panel: use __fallthrough

 drivers/auxdisplay/panel.c  |  6 +++---
 include/linux/compiler_attributes.h | 18 ++
 2 files changed, 21 insertions(+), 3 deletions(-)

-- 
2.17.1

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 12:27 AM Theodore Y. Ts'o  wrote:
>
> On Sun, Oct 21, 2018 at 07:14:13PM +0200, Miguel Ojeda wrote:
> > From the GCC manual:
> >
> >   fallthrough
> >
> > The fallthrough attribute with a null statement serves as a
> > fallthrough statement. It hints to the compiler that a statement
> > that falls through to another case label, or user-defined label
> > in a switch statement is intentional and thus the -Wimplicit-fallthrough
> > warning must not trigger. The fallthrough attribute may appear
> > at most once in each attribute list, and may not be mixed with
> > other attributes. It can only be used in a switch statement
> > (the compiler will issue an error otherwise), after a preceding
> > statement and before a logically succeeding case label,
> > or user-defined label.
> >
> >   https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html
>
> Do we know if coverity understands the fallthrough attribute?  One of
> the reasons why I started using /* fallthrough */ is because it kept
> Coverity happy.

If Coverity is like gcc, they should be doing both (i.e. I see the
comment parsing as an "extra" that gcc did, but the "basic stuff" is
the attribute -- and I would guess it is way easier for them to
support than the comment parsing).

But I cannot test it myself :-( Someone, please?

However, if I understood Greg correctly in his reply to the cover
letter, he replied that Coverity knows about it (?).

>
> If the conversion from /* fallthrough */ to the __fallthrough__
> attribute means that we start gethting a lot of Coverity warnings,
> that would be unfortunate.  OTOH, if this is getting standardized,
> maybe we can get Coverity to understand this attribute?

Indeed! That would be the best for everyone, including Coverity customers.

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 2:42 AM Matthew Wilcox  wrote:
>
> On Sun, Oct 21, 2018 at 07:14:13PM +0200, Miguel Ojeda wrote:
> > +#if __has_attribute(__fallthrough__)
> > +# define __fallthrough  __attribute__((__fallthrough__))
> > +#else
> > +# define __fallthrough
> > +#endif
>
> Why is the #else not:
>
> # define __fallthrough  /* fallthrough */
>
> Would this solve the Coverity problem, or does Coverity look at the raw
> source code before preprocessing?

That wouldn't work if Coverity follows the standard, because it is
required that comments are removed right before the preprocessing
phase.

That is one of the advantages vs. the attribute that I mentioned:

"""
We can actually use a #define for it like for the rest of
attributes/extensions, which is not possible with a comment, (...)
"""

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 11:36 AM Kees Cook  wrote:
>
> We need to make sure the static analyzers are happy with either
> method. Additionally, when was -Wimplicit-fallthrough added to GCC? If
> it was added _before_ the attribute, we need to continue using the
> comment style otherwise we lose coverage even with gcc itself.
> Additionally, does Clang support this attribute (it supports
> -Wimplicit-fallthrough).

Please take a look at the rationale (also more details at the linked thread):

  * gcc 7.1 added -Wimplicit-fallthrough at the same time as the
attribute and the comment parsing.
  * clang does *not* support the attribute in C.

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 11:41 AM Miguel Ojeda
 wrote:
>
>   * clang does *not* support the attribute in C.

...nor the warning at all, by the way (which is why this is OK).

Cheers,
Miguel

Re: [PATCH 0/2] Compiler Attributes: __fallthrough

[Miguel Ojeda]

On Sun, Oct 21, 2018 at 8:29 PM Greg Kroah-Hartman
 wrote:
>
> On Sun, Oct 21, 2018 at 07:14:12PM +0200, Miguel Ojeda wrote:
> > These are two patches are meant to go on top of the rest of the compiler
> > attributes series on:
> >
> >   https://github.com/ojeda/linux/tree/compiler-attributes
> >
> > which will be sent to Greg for the next merge window.
> >
> > Please review them and let me know! (specially if someone is against
> > __fallthrough for some reason :-).
>
> Will this work with all of the static tools that are currently looking
> for the comment instead?  I know coverity handles that, what about
> others?

Thank you Greg, good question. I will try to keep all the information
we can get about the tools in the commit message.

I will also contact the different tools about this.

Cheers,
Miguel

Re: [PATCH 2/2] Compiler Attributes: auxdisplay: panel: use __fallthrough

[Miguel Ojeda]

On Sun, Oct 21, 2018 at 8:11 PM Joe Perches  wrote:
>
> On Sun, 2018-10-21 at 19:14 +0200, Miguel Ojeda wrote:
> > Let gcc know these cases are meant to fall through to the next label
> > by annotating them with the new __fallthrough statement attribute;
> > and remove the comment since it conveys the same information
> > (which was also parsed by gcc to suppress the warning).
>
> Instead of many individual conversion patches,
> perhaps a script to do all the conversions at once.

Note that this was only an example of the attribute (some people asked
for an example when introducing another one, so I preemptively did it
for this one).

Doing the conversion (and how :-) I left it for afterwards, if people
agree with the attribute.

>
> Maybe:
>
> pattern='(?:\/\*\s*fall(?:\s*|\s*\-\s*)thr(?:u|ough)\s*\*\/|\/\/\s*fall\s*thr(?:u|ough)\s*$)'
> git grep -P -i --name-only "$pattern" -- '*.[ch]' |
> xargs perl -p -i -e "s/$pattern/__fallthrough;/gi"


By the way, I checked first if coccinelle could match input comments,
but it doesn't, according to Julia. I am also thinking whether a
compiler plugin could easily do this, but I don't have my hopes high
given these are comments...

Also, regardless of how it is done, the patches need to be sent
individually to maintainers, no? I have a vague memory that big &
automated conversions were a bit frozen upon in the kernel. Greg...?

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 12:54 PM Dan Carpenter  wrote:
>
> Doing both is super ugly.  Let's just do comments until Eclipse gets
> updated.
>
> I had wanted to move to the attribute because that would simplify things
> in Smatch but it's not a huge deal to delay for another year.

I can re-send them later on, no problem. On the other hand, doing the
changes will push tools to get updated sooner ;-)

If tools were doing something as fancy as comment parsing for
diagnostics, they should have been updated with the attribute support
(either gcc's or C++17's) -- it has been more than a year now since
gcc 7.1 and the C++17 final draft. (Note that this does not apply for
things like clang, since they weren't doing comment parsing to begin
with.)

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 12:53 PM Kees Cook  wrote:
>
> On Mon, Oct 22, 2018 at 2:41 AM, Miguel Ojeda
>  wrote:
> > Please take a look at the rationale (also more details at the linked 
> > thread):
> >
> >   * gcc 7.1 added -Wimplicit-fallthrough at the same time as the
> > attribute and the comment parsing.
>
> Ah, perfect. I missed this. :)

No problem! I know the commit message is a bit too long, so I understand :)

>
> >   * clang does *not* support the attribute in C.
>
> Well that's not good. :)

I will see with clang if they plan to add it.

(By the way, if the "*not*" sounded rude, sorry; I wanted to emphasize
it is surprising that it doesn't -- I also assumed the opposite until
I checked it).

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 2:07 PM Luc Van Oostenryck
 wrote:
>
> On Sun, Oct 21, 2018 at 07:14:13PM +0200, Miguel Ojeda wrote:
> >
> > While comment parsing is a good idea to deal with old codebases
> > that used such a comment as documentation for humans, the best
> > solution is to use the attribute:
> >
> >   * It is a "real" part of the AST (=> better for tooling).
>
> This will create a problem for the recent versions of sparse which
> support __has_attribute() because sparse falsely pretends to support
> this attribute while, to play nice with -Wdeclaration-after-statement,
> it needs some adaptation to the parsing (it's actually seen not as a
> statement but as a declaration).  I'll see to fix it this evening.

No rush Luc! (I have sent the PR to Linus without this two patches for
the moment).

And thanks a lot for having being so quick to improve sparse to
support all these series!

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 1:24 PM Miguel Ojeda
 wrote:
>
> On Mon, Oct 22, 2018 at 12:53 PM Kees Cook  wrote:
> >
> > On Mon, Oct 22, 2018 at 2:41 AM, Miguel Ojeda
> >  wrote:
> >
> > >   * clang does *not* support the attribute in C.
> >
> > Well that's not good. :)
>
> I will see with clang if they plan to add it.
>

So I have looked in the clang sources and I have seen that clang is
already preparing for C2x: since clang >= 6 we can actually enable the
C++-like attributes with "-fdouble-square-bracket-attributes" in C
mode, which in turn makes the warning work in C mode and can be
suppressed with [[fallthrough]]. This would give us the warning also
in clang, which would be a win vs. the comments. Nick?

However, I don't see a way to enable [[fallthrough]] in C mode for gcc
>= 7.1 -- from a quick look, the C parser does not know about [[]]
attributes, so I don't think we can use [[fallthrough]] for both
compilers (yet).

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 7:17 PM Nick Desaulniers
 wrote:
>
> On Mon, Oct 22, 2018 at 2:43 AM Miguel Ojeda
>  wrote:
> >
> > On Mon, Oct 22, 2018 at 11:41 AM Miguel Ojeda
> >  wrote:
> > >
> > >   * clang does *not* support the attribute in C.
> >
> > ...nor the warning at all, by the way (which is why this is OK).
> >
> > Cheers,
> > Miguel
>
> Oh? We're going through and annotating all of Android's C++ source
> right now with it.
> https://clang.llvm.org/docs/DiagnosticsReference.html#wimplicit-fallthrough
>

Sure, but I am talking about the C mode only. Please read the previous
messages in the thread :-)

> Though it looks like the attribute syntax I like from GCC is not yet
> supported in Clang.

Indeed, that is what I explained in the last message.

> https://bugs.llvm.org/show_bug.cgi?id=37135
> https://github.com/ClangBuiltLinux/linux/issues/235
> I'll take a look at adding support.
>
> So Kees sent me this embarrassing example:
> https://godbolt.org/z/gV_c9_
> (try changing the language from C++ to C; it works)!  That's embarrassing!

Yup, that is what I have been testing yesterday -- see the linked
thread in the commit message for the summary of the results.

> https://bugs.llvm.org/show_bug.cgi?id=39382
> https://github.com/ClangBuiltLinux/linux/issues/236
> Will get these both fixed up.

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 7:36 PM Nick Desaulniers
 wrote:
>
> On Sun, Oct 21, 2018 at 10:14 AM Miguel Ojeda
>  wrote:
> >
> > of its kind) to deal with this: [[fallthrough]] is meant to be
> > a new control keyword in the form of an extension.
>
> I think we can leave the details about the [[]] notation out. IIUC,
> it's only applicable to C++.

No, because C++ is the driving force for the standard attributes
syntax; i.e. C2x is adding them because of the syntax published by
C++17; and possibly gcc 7.1 added support for fallthrough (and comment
parsing) due to C++17 too.

Basically, it is a small paragraph explaining how this came to be.

> > +#if __has_attribute(__fallthrough__)
> > +# define __fallthrough  __attribute__((__fallthrough__))
> > +#else
> > +# define __fallthrough
>
> While this is in the correct format as the other attributes in this
> file, I think this particular attribute is a special case, because of
> the variety of fallbacks and differing support for them.  I'd like to

No, is it the correct format because we cannot add support for the
other syntax in gcc; so the best way to proceed is to simply wait
until clang supports the GNU attribute in C mode.

The tooling, of course, is another matter and independent of this.

> see in the commit message maybe a list of tools we'd like to support

Yes, I already said I would write it in one of the other threads.

> and links to the feature requests/bug reports for them.  I acknowledge
> it's more work to file bugs, but it's being a good open source
> citizen, IMO.

Who said we aren't going to do it? :-)

I was actually in the process of checking which OSS tools supported
what and how easy it was to fix in each of them (gcc's [[...]] syntax,
clang's GNU and C++ attrs in C mode, cppcheck's fallthrough
support...), but it takes time; I prefer to do the research
beforehand; so that the submitted bug reports are better/more
precise/more helpful, etc.

However, you already sent the LLVM report (without mentioning this
thread or me, nor the -fdouble-square-bracket-attributes clang flag
that I mentioned). That is a bit rude :-) Please take things a little
easier, there is no need to rush stuff. If I didn't have submitted the
LLVM bug report is because I hadn't finish looking at the issue. In
general, I think it is polite (and also more productive to avoid
duplicating efforts) to first ask whoever is working on something
before you rush to do it...

>
> I'm also curious which is the first version of GCC to support the
> comment format?

gcc 7.1 started everything. It is stated in the commit message and
several messages/threads already. Again, please pause, relax and read
a bit before sending stuff around :-)

Cheers,
Miguel

Re: [PATCH 0/2] Compiler Attributes: __fallthrough

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 6:54 PM Nick Desaulniers
 wrote:
>
> On Mon, Oct 22, 2018 at 2:48 AM Miguel Ojeda
>  wrote:
> >
> > On Sun, Oct 21, 2018 at 8:29 PM Greg Kroah-Hartman
> >  wrote:
> > >
> > > Will this work with all of the static tools that are currently looking
> > > for the comment instead?  I know coverity handles that, what about
> > > others?
> >
> > I will also contact the different tools about this.
>
> Let's contact the authors of these tools if they don't parse the
> attribute.  I prefer to have the attributes rather than specifically
> formatted comments.

Sorry, not sure what you mean -- isn't that what I said? Greg was
asking whether tools would support the attribute equally well compared
to the comment parsing; not the comments.

>
> I do think this may be tricky to provide backwards support for though;
> Miguel, do you have info on which versions of GCC support comments vs
> attribute?

It is in the commit message:

"""
In C mode, GCC supports the __fallthrough__ attribute since 7.1,
the same time the warning and the comment parsing were introduced.
"""

Cheers,
Miguel

Re: [PATCH 1/2] Compiler Attributes: add support for __fallthrough (gcc >= 7.1)

[Miguel Ojeda]

On Mon, Oct 22, 2018 at 7:50 PM Bernd Petrovitsch
 wrote:
>
> Hi all!
>
> On 22/10/18 13:07, Miguel Ojeda wrote:
> > On Mon, Oct 22, 2018 at 12:54 PM Dan Carpenter  
> > wrote:
> >>
> >> Doing both is super ugly.  Let's just do comments until Eclipse gets
> >> updated.
>
> Yes, "Eclipse" as the IDE.
>
> And yes but IMHO better super ugly than loosing the warning - YMMV.

I think Dan meant too simply not touch anything (i.e. not losing the
warning anywhere).

>
> For the archives: I have Eclipse Photon/June 2016 here. And "no break"
> is the (default) string in a comment used by Eclipse (it can be
> customized and is actually a regexp but it must be in a comment).
>

Hm... that means they don't support (by default) the same regexps as
GCC; which is bad: it means that it is only equivalent to the most
relaxed level in gcc, 1:

"""
-Wimplicit-fallthrough=1 matches .* regular expression, any
comment is used as fallthrough comment.
"""

See https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html

i.e. any other level above will either not match Eclipse or not match gcc.

> >> I had wanted to move to the attribute because that would simplify things
> >> in Smatch but it's not a huge deal to delay for another year.
> >
> > I can re-send them later on, no problem. On the other hand, doing the
> > changes will push tools to get updated sooner ;-)
> >
> > If tools were doing something as fancy as comment parsing for
> > diagnostics, they should have been updated with the attribute support
> > (either gcc's or C++17's) -- it has been more than a year now since
> > gcc 7.1 and the C++17 final draft. (Note that this does not apply for
> > things like clang, since they weren't doing comment parsing to begin
> > with.)
>
> That would be nice. And if they agree on the same texts (or accept per
> default all somewhat widely used and/or old ones).
>
> After stumbling over
> https://stackoverflow.com/questions/16935935/how-do-i-turn-off-a-static-code-analysis-warning-on-a-line-by-line-warning-in-cd,
> looking into Eclipses Window -> Preferences -> C/C++ -> Code Analysis ->
> "No break at the end of case" screen (that's the screenshot there) and I
> tried various things:
>
> Preface:
> I have
>   snip  
> #define __fallthrough __attribute__((fallthrough))
>   snip  
> for gcc >= 7 (because clang doesn't know it and I had also older
> gcc's in use before).
>
> So:
> - Adding a comment to the #define doesn't change anything for Eclipse.

It shouldn't according to the standard -- but who knows... :-)

> - Eclipse looks *only* in comments for the string/regexp given
>   the warnings configuration (and that comment must be on the line
>   directly before the "case").
> - Eclipse understands [[fallthrough]] out-of-the-box though (which
>   is C++11 AFAIK) as does g++-7 (I use -std=gnu++17 - most of the
>   sources are C++, but not all) and clang++-6 (all the current standard
>   Ubuntu-18.06/Bionic packages).

Eclipse understanding [[fallthrough]] is very good, actually.

>   Eclipse "accepts" [[fallthrough]] only in C++ sources (and not in C
>   sources).

Bad, but I guess they will add it to C eventually, since it is
probably coming for C2x.

> - Neither gcc nor clang understand [[fallthrough]] (so it's probably a
>   no-go for the Kernel with C89 anyways).

clang does it if you enable -fdouble-square-bracket-attributes (please
see my other messages). gcc will at some point (if C2x gets the
attributes), but at the moment the C parser is different than the C++
parser and there is no support for it on trunk that I could see, so
they will have to copy the support; i.e. it will take a bit more time
than clang, likely.

Thanks a *lot* for taking a look at Eclipse!

Cheers,
Miguel

Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES

[Miguel Ojeda]

On Fri, Oct 26, 2018 at 7:27 PM Colin King  wrote:
>
> From: Colin Ian King 
>
> Trivial fix to a spelling mistake of the error access name EACCESS,
> rename to EACCES

? It is not a typo, it is the name of the error (POSIX). Same thing
for the rest of the patches.

Cheers,
Miguel

Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES

[Miguel Ojeda]

On Fri, Oct 26, 2018 at 8:40 PM Matthew Wilcox  wrote:
>
> On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote:
> > On Fri, Oct 26, 2018 at 7:27 PM Colin King  wrote:
> > >
> > > From: Colin Ian King 
> > >
> > > Trivial fix to a spelling mistake of the error access name EACCESS,
> > > rename to EACCES
> >
> > ? It is not a typo, it is the name of the error (POSIX). Same thing
> > for the rest of the patches.
>
> Are you sure?  From open(2):
>
>EACCES The  requested access to the file is not allowed, or search per‐
>   mission is denied for one of the directories in the path  prefix
>   of  pathname,  or the file did not exist yet and write access to
>   the parent directory is not  allowed.   (See  also  path_resolu‐
>   tion(7).)
>
> include/uapi/asm-generic/errno-base.h:#define   EACCES  13  /* 
> Permission denied */

I thought you were doing the reverse change. Never mind! :-)

(Btw, the POSIX reference is
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html#tag_13_09,
in case you want to include it or are curious)

Cheers,
Miguel

Re: [PATCH] Documentation: fix spelling mistake, EACCESS -> EACCES

[Miguel Ojeda]

On Fri, Oct 26, 2018 at 8:53 PM Miguel Ojeda
 wrote:
>
> On Fri, Oct 26, 2018 at 8:40 PM Matthew Wilcox  wrote:
> >
> > On Fri, Oct 26, 2018 at 08:20:12PM +0200, Miguel Ojeda wrote:
> > > On Fri, Oct 26, 2018 at 7:27 PM Colin King  
> > > wrote:
> > > >
> > > > From: Colin Ian King 
> > > >
> > > > Trivial fix to a spelling mistake of the error access name EACCESS,
> > > > rename to EACCES
> > >
> > > ? It is not a typo, it is the name of the error (POSIX). Same thing
> > > for the rest of the patches.
> >
> > Are you sure?  From open(2):
> >
> >EACCES The  requested access to the file is not allowed, or search 
> > per‐
> >   mission is denied for one of the directories in the path  
> > prefix
> >   of  pathname,  or the file did not exist yet and write access 
> > to
> >   the parent directory is not  allowed.   (See  also  
> > path_resolu‐
> >   tion(7).)
> >
> > include/uapi/asm-generic/errno-base.h:#define   EACCES  13  /* 
> > Permission denied */
>
> I thought you were doing the reverse change. Never mind! :-)
>
> (Btw, the POSIX reference is
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html#tag_13_09,
> in case you want to include it or are curious)

Sorry Matthew, thought I was answering to Colin. I should go to rest.

Cheers,
Miguel

Re: [PATCH 2/2] Compiler Attributes: auxdisplay: panel: use __fallthrough

[Miguel Ojeda]

Hi Dan,

On Tue, Oct 23, 2018 at 7:37 AM Dan Carpenter  wrote:
>
> On Mon, Oct 22, 2018 at 07:10:02AM -0700, Kees Cook wrote:
> > I would prefer we continue to use the comment style until we've got
> > confirmed support for (at least) Clang, Coverity, CPPcheck, smatch,
> > and eclipse.
>
> Clang and Smatch don't support fall throught comments.  Coverity
> supports both.  CPPcheck is unknown.
>
> Eclipse doesn't support attributes.  So it's just Eclipse and maybe
> CPP check.

Thanks for checking! Let's wait then a few months and see if we can
get cppcheck/Eclipse to support it.

Cheers,
Miguel

Re: [PATCH 2/2] Compiler Attributes: auxdisplay: panel: use __fallthrough

[Miguel Ojeda]

On Fri, Nov 2, 2018 at 11:49 AM Miguel Ojeda
 wrote:
>
> Thanks for checking! Let's wait then a few months and see if we can
> get cppcheck/Eclipse to support it.

In the meantime, saved here too:

  https://github.com/ojeda/linux/tree/compiler-attributes-fallthrough

rebased on top of e468f5c06b5e ("Merge tag
'compiler-attributes-for-linus-4.20-rc1' of
https://github.com/ojeda/linux";).

Cheers,
Miguel

Re: [PATCH v2 02/29] docs: lcd-panel-cgram.txt: convert docs to ReST and rename to *.rst

[Miguel Ojeda]

On Tue, Jun 18, 2019 at 10:56 PM Mauro Carvalho Chehab
 wrote:
>
> This small text file describes the usage of parallel port LCD
> displays from userspace PoV. So, a good candidate for the
> admin guide.
>
> While this is not part of the admin-guide book, mark it as
> :orphan:, in order to avoid build warnings.

If we are going to move everything else to `.rst` too, even things
outside the guide, then ack.

Cheers,
Miguel

Re: [PATCH v2 02/29] docs: lcd-panel-cgram.txt: convert docs to ReST and rename to *.rst

[Miguel Ojeda]

On Wed, Jun 19, 2019 at 1:15 AM Mauro Carvalho Chehab
 wrote:
>
> Yeah, the plan is to move all text files inside Documentation/ to .rst[1].
>
> [1] There are some exceptions: for ABI and features, the current plan
> is to have a script that parses their strict formats and produce
> a ReST output.
>
>
> Btw, Still pending to be sent, I have already a patch removing the
> :orphan: from this file and adding it to the admin guide:
>
> 
> https://git.linuxtv.org/mchehab/experimental.git/commit/?h=convert_rst_renames_v5.1&id=eae5b48cab115c83be8dd59ee99b9e45f8142134
>
> And the corresponding output, after the patches I currently have:
>
> 
> https://www.infradead.org/~mchehab/rst_conversion/admin-guide/lcd-panel-cgram.html

Thanks for the pointers! I guess you will take all these
patches/series on your tree(s), but if you want maintainers to do it,
please let me know!

Cheers,
Miguel

Re: [PATCH 07/22] docs: admin-guide: add auxdisplay files to it after conversion to ReST

[Miguel Ojeda]

On Mon, Jul 22, 2019 at 1:08 PM Mauro Carvalho Chehab
 wrote:
>
> Those two files describe userspace-faced information. While part of
> it might fit on uAPI, it sounds to me that the admin guide is the
> best place for them.

Acked-by: Miguel Ojeda 

Thanks a lot for all the work on the Docs, Mauro!

On the topic of these files: don't worry too much about these, they
are old drivers (they used the parallel port, which probably nobody
has anymore :-) so I should remove them at some point, I guess.

Cheers,
Miguel

Re: [PATCH v2 7/8] [PATCH 7/8] drivers/hwmon: Add a generic PECI hwmon client driver

[Miguel Ojeda]

On Thu, Feb 22, 2018 at 2:29 AM, Jae Hyun Yoo
 wrote:
> On 2/21/2018 4:37 PM, Andrew Lunn wrote:
>>>
>>> But even with this change, it still needs to use delayed creation
>>> because BMC side kernel doesn't know how many DIMMs are populated on
>>> a remote server before the remote server completes its memory
>>> training and testing in BIOS, but it needs to check the remote
>>> server's CPU temperature as immediate as possible to make
>>> appropriate thermal control based on the remote CPU's temperature to
>>> avoid any critical thermal issue. What would be a better solution in
>>> this case?
>>
>>
>> You could change this driver so that it supports one DIMM.  Move the
>> 'hotplug' part into another driver which creates and destroys
>> instances of the hwmon DIMM device as the DIMMS come and go.
>>
>> Also, do you need to handle CPU hotplug? You could split the CPU
>> temperature part into a separate hwmon driver? And again create and
>> destroy devices as CPUs come and go?
>>
>> Andrew
>>
>
> That seems like a possible option. I'll rewrite the hwmon driver again like
> that.
>
> Thanks for the good idea. :)

By the way, in the rewrite, please try to avoid the create*workqueue()
functions (they are deprecated :).

Cheers,
Miguel

>
> Jae
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Doc: misc-devices: move lcd-panel-cgram.txt to auxdisplay/

[Miguel Ojeda]

Commit 7005b58458e4beecaf5efacb872c456bc7d3541a ("Staging: add lcd-panel
driver") introduced the panel driver, which is now in
drivers/auxdisplay.

Cc: Willy Tarreau 
Cc: Jonathan Corbet 
Signed-off-by: Miguel Ojeda 
---
 Documentation/{misc-devices => auxdisplay}/lcd-panel-cgram.txt | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/{misc-devices => auxdisplay}/lcd-panel-cgram.txt (100%)

diff --git a/Documentation/misc-devices/lcd-panel-cgram.txt 
b/Documentation/auxdisplay/lcd-panel-cgram.txt
similarity index 100%
rename from Documentation/misc-devices/lcd-panel-cgram.txt
rename to Documentation/auxdisplay/lcd-panel-cgram.txt
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/4] Documentation/process: Add fallthrough pseudo-keyword

[Miguel Ojeda]

On Sat, Oct 5, 2019 at 6:47 PM Joe Perches  wrote:
>
> diff --git a/Documentation/process/deprecated.rst 
> b/Documentation/process/deprecated.rst
> index 56280e108d5a..a0ffdc8daef3 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -122,14 +122,27 @@ memory adjacent to the stack (when built without 
> `CONFIG_VMAP_STACK=y`)
>
>  Implicit switch case fall-through
>  -
> -The C language allows switch cases to "fall through" when
> -a "break" statement is missing at the end of a case. This,
> -however, introduces ambiguity in the code, as it's not always
> -clear if the missing break is intentional or a bug. As there
> -have been a long list of flaws `due to missing "break" statements
> +The C language allows switch cases to "fall-through" when a "break" statement
> +is missing at the end of a case. This, however, introduces ambiguity in the
> +code, as it's not always clear if the missing break is intentional or a bug.
> +
> +As there have been a long list of flaws `due to missing "break" statements
>  `_, we no longer allow
> -"implicit fall-through". In order to identify an intentional fall-through
> -case, we have adopted the marking used by static analyzers: a comment
> -saying `/* Fall through */`. Once the C++17 `__attribute__((fallthrough))`
> -is more widely handled by C compilers, static analyzers, and IDEs, we can
> -switch to using that instead.
> +"implicit fall-through".
> +
> +In order to identify intentional fall-through cases, we have adopted a
> +pseudo-keyword macro 'fallthrough' which expands to gcc's extension
> +__attribute__((__fallthrough__)).  `Statement Attributes
> +`_
> +
> +When the C17/C18  [[fallthrough]] syntax is more commonly supported by

Note that C17/C18 does not have [[fallthrough]]. C++17 introduced it,
as it is mentioned above. I would keep the
__attribute__((fallthrough)) -> [[fallthrough]] change you did,
though, since that is indeed the standard syntax (given the paragraph
references C++17).

I was told by Aaron Ballman (who is proposing them for C) that it is
more or less likely that it becomes standardized in C2x. However, it
is still not added to the draft (other attributes are already,
though). See N2268 and N2269:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2268.pdf (fallthrough)
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2269.pdf
(attributes in general)

Cheers,
Miguel

Re: [PATCH 0/4] treewide: Add 'fallthrough' pseudo-keyword

[Miguel Ojeda]

Hi Linus,

On Fri, Oct 11, 2019 at 6:30 PM Linus Torvalds
 wrote:
>
> On Sat, Oct 5, 2019 at 9:46 AM Joe Perches  wrote:
> >
> > Add 'fallthrough' pseudo-keyword to enable the removal of comments
> > like '/* fallthrough */'.
>
> I applied patches 1-3 to my tree just to make it easier for people to
> start doing this. Maybe some people want to do the conversion on their
> own subsystem rather than with a global script, but even if not, this
> looks better as a "prepare for the future" series and I feel that if
> we're doing the "fallthrough" thing eventually, the sooner we do the
> prepwork the better.
>
> I'm a tiny bit worried that the actual conversion is just going to
> cause lots of pain for the stable people, but I'll not worry about it
> _too_ much. If the stable people decide that it's too painful for them
> to deal with the comment vs keyword model, they may want to backport
> these three patches too.

I was waiting for a v2 series to pick it up given we had some pending changes...

Cheers,
Miguel

Re: [PATCH 0/4] treewide: Add 'fallthrough' pseudo-keyword

[Miguel Ojeda]

On Sat, Oct 12, 2019 at 12:08 AM Kees Cook  wrote:
>
> On Fri, Oct 11, 2019 at 08:01:42PM +0200, Miguel Ojeda wrote:
> > Hi Linus,
> >
> > On Fri, Oct 11, 2019 at 6:30 PM Linus Torvalds
> >  wrote:
> > >
> > > On Sat, Oct 5, 2019 at 9:46 AM Joe Perches  wrote:
> > > >
> > > > Add 'fallthrough' pseudo-keyword to enable the removal of comments
> > > > like '/* fallthrough */'.
> > >
> > > I applied patches 1-3 to my tree just to make it easier for people to
> > > start doing this. Maybe some people want to do the conversion on their
> > > own subsystem rather than with a global script, but even if not, this
> > > looks better as a "prepare for the future" series and I feel that if
> > > we're doing the "fallthrough" thing eventually, the sooner we do the
> > > prepwork the better.
> > >
> > > I'm a tiny bit worried that the actual conversion is just going to
> > > cause lots of pain for the stable people, but I'll not worry about it
> > > _too_ much. If the stable people decide that it's too painful for them
> > > to deal with the comment vs keyword model, they may want to backport
> > > these three patches too.
> >
> > I was waiting for a v2 series to pick it up given we had some pending 
> > changes...
>
> Hmpf, looks like it's in torvalds/master now. Miguel, most of the changes
> were related to the commit log, IIRC, so that ship has sailed. :( Can the
> stuff in Documentation/ be improved with a follow-up patch, perhaps?

Linus seems to have applied some of the improvements to the commit
messages, but not those to the content (not sure why, since they were
also easy ones). But no worries, we will do those later :)

Cheers,
Miguel

[PATCH 3/3] rust: upgrade to Rust 1.73.0

[Miguel Ojeda]

This is the next upgrade to the Rust toolchain, from 1.72.1 to 1.73.0
(i.e. the latest) [1].

See the upgrade policy [2] and the comments on the first upgrade in
commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2").

# Unstable features

No unstable features (that we use) were stabilized.

Therefore, the only unstable feature allowed to be used outside
the `kernel` crate is still `new_uninit`, though other code to be
upstreamed may increase the list.

Please see [3] for details.

# Required changes

For the upgrade, the following changes are required:

  - Allow `internal_features` for `feature(compiler_builtins)` since
now Rust warns about using internal compiler and standard library
features (similar to how it also warns about incomplete ones) [4].

  - A cleanup for a documentation link thanks to a new `rustdoc` lint.
See previous commits for details.

  - A need to make an intra-doc link to a macro explicit, due to a
change in behavior in `rustdoc`. See previous commits for details.

# `alloc` upgrade and reviewing

The vast majority of changes are due to our `alloc` fork being upgraded
at once.

There are two kinds of changes to be aware of: the ones coming from
upstream, which we should follow as closely as possible, and the updates
needed in our added fallible APIs to keep them matching the newer
infallible APIs coming from upstream.

Instead of taking a look at the diff of this patch, an alternative
approach is reviewing a diff of the changes between upstream `alloc` and
the kernel's. This allows to easily inspect the kernel additions only,
especially to check if the fallible methods we already have still match
the infallible ones in the new version coming from upstream.

Another approach is reviewing the changes introduced in the additions in
the kernel fork between the two versions. This is useful to spot
potentially unintended changes to our additions.

To apply these approaches, one may follow steps similar to the following
to generate a pair of patches that show the differences between upstream
Rust and the kernel (for the subset of `alloc` we use) before and after
applying this patch:

# Get the difference with respect to the old version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > old.patch
git -C linux restore rust/alloc

# Apply this patch.
git -C linux am rust-upgrade.patch

# Get the difference with respect to the new version.
git -C rust checkout $(linux/scripts/min-tool-version.sh rustc)
git -C linux ls-tree -r --name-only HEAD -- rust/alloc |
cut -d/ -f3- |
grep -Fv README.md |
xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH
git -C linux diff --patch-with-stat --summary -R > new.patch
git -C linux restore rust/alloc

Now one may check the `new.patch` to take a look at the additions (first
approach) or at the difference between those two patches (second
approach). For the latter, a side-by-side tool is recommended.

Link: 
https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1730-2023-10-05
 [1]
Link: https://rust-for-linux.com/rust-version-policy [2]
Link: https://github.com/Rust-for-Linux/linux/issues/2 [3]
Link: https://github.com/rust-lang/compiler-team/issues/596 [4]
Signed-off-by: Miguel Ojeda 
---
 Documentation/process/changes.rst |  2 +-
 rust/alloc/alloc.rs   | 22 --
 rust/alloc/boxed.rs   | 48 ---
 rust/alloc/lib.rs |  5 ++--
 rust/alloc/raw_vec.rs | 30 ---
 rust/alloc/vec/mod.rs |  4 +--
 rust/alloc/vec/spec_extend.rs |  8 +++---
 rust/compiler_builtins.rs |  1 +
 scripts/min-tool-version.sh   |  2 +-
 9 files changed, 63 insertions(+), 59 deletions(-)

diff --git a/Documentation/process/changes.rst 
b/Documentation/process/changes.rst
index 731cc104c56f..bb96ca0f774b 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -31,7 +31,7 @@ you probably needn't concern yourself with pcmciautils.
 == ===  

 GNU C  5.1  gcc --version
 Clang/LLVM (optional)  11.0.0   clang --version
-Rust (optional)1.72.1   rustc --version
+Rust (optional)1.73.0   rustc --version
 bindgen (optional) 0.65.1   bindgen --version
 GNU make   3.82 make --version
 bash   4.2  bash --version
diff --git a/rust/alloc/alloc.rs b/rust/alloc/alloc.rs
index 51821feb20b1..8cb4a31cf6e5 100644
--- a/rust/alloc/alloc.rs
+++ b/rust/alloc/alloc.rs
@@ 

RE: [PATCH v3] Documentation/process/coding-style.rst: space around const

[Miguel Ojeda]

On Wed, 11 Oct 2023 14:44:17 -0700, Dan Williams wrote:
>
> I notice that clang-format reflows that example to:
>
> const void *a;
> void *const b;
> void **const c;
> void *const *const d;
> int strcmp(const char *a, const char *b);
>
> ...but someone more clang-format savvy than me would need to propose the
> changes to the kernel's .clang-format template to match the style
> suggestion.

I think we could use:

diff --git a/.clang-format b/.clang-format
index 0bbb1991defe..9eeb511c0814 100644
--- a/.clang-format
+++ b/.clang-format
@@ -671,6 +671,7 @@ SortIncludes: false
 SortUsingDeclarations: false
 SpaceAfterCStyleCast: false
 SpaceAfterTemplateKeyword: true
+SpaceAroundPointerQualifiers: Both
 SpaceBeforeAssignmentOperators: true
 SpaceBeforeCtorInitializerColon: true
 SpaceBeforeInheritanceColon: true

At least that makes it match the documentation example -- I got this:

const void *a;
void * const b;
void ** const c;
void * const * const d;
int strcmp(const char *a, const char *b);

But it is only supported in version >= 12, so we need to wait for the
minimum LLVM version bump.

(Thanks for the ping, Joe!)

Cheers,
Miguel

Re: [PATCH v3] Documentation/process/coding-style.rst: space around const

[Miguel Ojeda]

On Thu, Oct 12, 2023 at 4:48 PM Joe Perches  wrote:
>
> Do older versions of clang-format ignore entries
> they don't understand?

Sadly, no, that is the reason we keep it at the minimum.

However, I just took a look again at it, and I see that such support
was added to LLVM 12, the `--Wno-error=unknown` flag in commit
f64903fd8176 ("Add -Wno-error=unknown flag to clang-format.").

So this means that the minimum is bumped to 12, we could in principle
use newer options.

I think the downsides are that users will need to pass the flag
(potentially in e.g. their IDE or similar) and that formatting could
be potentially chaotic depending on the options ignored. I guess
particular subsystems could agree on which version to use.

Cheers,
Miguel

Re: [PATCH 4/7] Docs: Move clang-format from process/ to dev-tools/

[Miguel Ojeda]

On Mon, Jun 24, 2024 at 8:53 PM SeongJae Park  wrote:
>
> 'clang-format' is on 'Other material' section of 'process/index', but it
> may fit more under 'dev-tools/' directory.  Move it.
>
> Signed-off-by: SeongJae Park 

Happy either way -- thanks!

Acked-by: Miguel Ojeda 

Cheers,
Miguel

[PATCH 06/13] rust: start supporting several compiler versions

[Miguel Ojeda]

It is time to start supporting several Rust compiler versions and thus
establish a minimum Rust version.

We may still want to upgrade the minimum sometimes in the beginning since
there may be important features coming into the language that improve
how we write code (e.g. field projections), which may or may not make
sense to support conditionally.

We will start with a window of two stable releases, and widen it over
time. Thus this patch does not move the current minimum (1.78.0), but
instead adds support for the recently released 1.79.0.

This should already be enough for kernel developers in distributions that
provide recent Rust compiler versions routinely, such as Arch Linux,
Debian Unstable (outside the freeze period), Fedora Linux, Gentoo
Linux (especially the testing channel), Nix (unstable) and openSUSE
Tumbleweed. See the documentation patch about it later in this series.

In addition, Rust for Linux is now being built-tested in Rust's pre-merge
CI [1]. That is, every change that is attempting to land into the Rust
compiler is tested against the kernel, and it is merged only if it passes
-- thanks to the Rust project for that!

Thus, with the pre-merge CI in place, both projects hope to avoid
unintentional changes to Rust that break the kernel. This means that,
in general, apart from intentional changes on their side (that we will
need to workaround conditionally on our side), the upcoming Rust compiler
versions should generally work.

For instance, currently, the beta (1.80.0) and nightly (1.81.0) branches
work as well.

Of course, the Rust for Linux CI job in the Rust toolchain may still need
to be temporarily disabled for different reasons, but the intention is
to help bring Rust for Linux into stable Rust.

Link: https://github.com/rust-lang/rust/pull/125209 [1]
Signed-off-by: Miguel Ojeda 
---
 Documentation/process/changes.rst  | 4 +---
 Documentation/rust/quick-start.rst | 9 -
 scripts/rust_is_available.sh   | 8 
 scripts/rust_is_available_test.py  | 5 -
 4 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/Documentation/process/changes.rst 
b/Documentation/process/changes.rst
index 5685d7bfe4d0..0d0b7120792b 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -88,9 +88,7 @@ docs on :ref:`Building Linux with Clang/LLVM `.
 Rust (optional)
 ---
 
-A particular version of the Rust toolchain is required. Newer versions may or
-may not work because the kernel depends on some unstable Rust features, for
-the moment.
+A recent version of the Rust compiler is required.
 
 Each Rust toolchain comes with several "components", some of which are required
 (like ``rustc``) and some that are optional. The ``rust-src`` component (which
diff --git a/Documentation/rust/quick-start.rst 
b/Documentation/rust/quick-start.rst
index cc3f11e0d441..139a8a536838 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -29,16 +29,15 @@ if that is the case.
 rustc
 *
 
-A particular version of the Rust compiler is required. Newer versions may or
-may not work because, for the moment, the kernel depends on some unstable
-Rust features.
+A recent version of the Rust compiler is required.
 
 If ``rustup`` is being used, enter the kernel build directory (or use
-``--path=`` argument to the ``set`` sub-command) and run::
+``--path=`` argument to the ``set`` sub-command) and run,
+for instance::
 
rustup override set $(scripts/min-tool-version.sh rustc)
 
-This will configure your working directory to use the correct version of
+This will configure your working directory to use the given version of
 ``rustc`` without affecting your default toolchain.
 
 Note that the override applies to the current working directory (and its
diff --git a/scripts/rust_is_available.sh b/scripts/rust_is_available.sh
index 117018946b57..67cb900124cc 100755
--- a/scripts/rust_is_available.sh
+++ b/scripts/rust_is_available.sh
@@ -117,14 +117,6 @@ if [ "$rust_compiler_cversion" -lt 
"$rust_compiler_min_cversion" ]; then
echo >&2 "***"
exit 1
 fi
-if [ "$rust_compiler_cversion" -gt "$rust_compiler_min_cversion" ]; then
-   echo >&2 "***"
-   echo >&2 "*** Rust compiler '$RUSTC' is too new. This may or may not 
work."
-   echo >&2 "***   Your version: $rust_compiler_version"
-   echo >&2 "***   Expected version: $rust_compiler_min_version"
-   echo >&2 "***"
-   warning=1
-fi
 
 # Check that the Rust bindings generator is suitable.
 #
diff --git a/scripts/rust_is_available_test.py 
b/scripts/rust_is_available_test.py
index 57613fe5ed75..a255f79aafc2 100755
--- a/scripts/rust_is_available_test.py
+++ b/scripts/rust_is_available_test.py
@@ -193,11 +193,6 @@ else:
 result = self.run_script(self.Expe

Re: [PATCH 06/13] rust: start supporting several compiler versions

[Miguel Ojeda]

On Thu, Jul 4, 2024 at 4:45 PM Finn Behrens  wrote:
>
> One idea below, but fine with or without it.
>
> Reviewed-by: Finn Behrens 

Thanks Finn!

> Would it make sense to not advise the min version but the “max” or just 
> latest stable version? Min version should work as well latest could 
> potentially be a bit more optimised if both work either way?

Yeah, that is a good idea -- we could just say `stable` there.

In fact, it makes more sense, because this is using `rustup`, i.e. the
Rust-provided binaries, and the Rust project only supports the latest
version (so far -- there are proposals about LTSs there).

Cheers,
Miguel

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Miguel Ojeda]

On Fri, Jul 5, 2024 at 8:19 AM Andrea Righi  wrote:
>
> This implicitly covers Ubuntu, since packages are sync'ed with Debian.

Do you mean the names (i.e. command) is the same, or that the newer
versions from e.g. Sid can be used in Ubuntu? If the latter, that
would be definitely worth adding, yeah -- is that supported / expected
to work?

> In addition to that Ubuntu also provides versioned packages (such as
> rustc-1.74, bindgen-0.65, etc.), so in case of special requirements
> (e.g., older kernels) users should be able to install the required
> version(s) using the packages provided by the distro.
>
> Maybe it's worth mentioning as a little note, so that users are aware of
> these extra packages.

I thought about adding a section for Ubuntu to mention those -- so far
I only added the distributions/commands that were likely to work with
the versions supported by the kernel, with the idea of expand later as
time passes. So I didn't add the versioned ones since the latest is
1.76, so it wouldn't work for the current kernel.

But it may be useful to state it nevertheless, since some people may
only look at the latest docs. (Or perhaps Ubuntu can add Rust 1.79? :)

Thanks!

Cheers,
Miguel

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Miguel Ojeda]

On Fri, Jul 5, 2024 at 8:47 AM Fabian Grünbichler
 wrote:
>
> Debian (for building firefox and chromium), and uses a -web suffix for
> that:
>
> https://tracker.debian.org/pkg/rustc-web

Like for Ubuntu's versioned ones, it seems not recent enough at the
moment (i.e. for the current kernel), if I understand correctly.

Also, it is a single version, i.e. 1.70, right? We didn't use that
particular version in any old kernel version (we moved from 1.68.2 to
1.71.1 in commit 89eed1ab1161 ("rust: upgrade to Rust 1.71.1") back
then). So I am not sure how useful it would be, but if you think it
will be in the future, perhaps it is worth mentioning.

> https://tracker.debian.org/pkg/rust-cbindgen-web

We may use `cbindgen` too in the future, but not currently.

Is something like `bindgen-web` also available for stable?

Thanks!

Cheers,
Miguel

Re: [PATCH 13/13] docs: rust: quick-start: add section on Linux distributions

[Miguel Ojeda]

On Fri, Jul 5, 2024 at 3:09 PM Fabian Grünbichler
 wrote:
>
> right now it is updated whenever its rdeps (firefox and chromium in
> stable) need newer versions. once e.g. a stable Debian kernel has
> similar requirements, I guess the same would apply there. I am not sure
> upstream kernel development on Debian stable would be enough of an
> argument to update it (or provide similar packages), but I am not a
> member of the teams that would make that decision.

That is reasonable.

> as discussed off-list, -backports might be a better place for providing
> more recent toolchain packages on Debian stable, and independent from
> this thread, I have pondered providing them there in the past already.
> backports would only ship one version as well though, and at most the
> one in testing (so it would also be affected by the freeze period, just
> like unstable and testing).

I imagine that could be useful for some (kernel or not) developers on
stable, even with the freeze period.

Thanks!

Cheers,
Miguel

[PATCH v2 00/13] Support several Rust toolchain versions

[Miguel Ojeda]

Hi all,

A few things improved here and there, and rebased on top of `rust-next`.

The changelog is attached to each patch.

I kept the `Tested-by`s since most of the changes are on documentation
or comments, though I did remove them on the patch that changed the most
just in case (even for that one, I think Benno's and Andreas' setup
would not have made a difference).

I plan to put this series into `rust-next` very soon so that it goes
into the merge window.

Previous cover letter:

  v1: 
https://lore.kernel.org/rust-for-linux/20240701183625.665574-1-oj...@kernel.org/

Thanks!

Cheers,
Miguel

Miguel Ojeda (13):
  rust: macros: indent list item in `paste!`'s docs
  rust: init: simplify from `map_err` to `inspect_err`
  rust: allow `dead_code` for never constructed bindings
  rust: relax most deny-level lints to warnings
  rust: simplify Clippy warning flags set
  rust: start supporting several compiler versions
  rust: avoid assuming a particular `bindgen` build
  rust: work around `bindgen` 0.69.0 issue
  rust: start supporting several `bindgen` versions
  rust: warn about `bindgen` versions 0.66.0 and 0.66.1
  kbuild: rust: add `rustc-version` support
  rust: support the new `-Zub-checks` flag
  docs: rust: quick-start: add section on Linux distributions

 Documentation/process/changes.rst|   9 +-
 Documentation/rust/quick-start.rst   | 136 +--
 Makefile |  31 +++---
 init/Kconfig |  11 +-
 lib/Kconfig.debug|  18 +++
 rust/Makefile|   4 +-
 rust/bindings/lib.rs |   1 +
 rust/kernel/init.rs  |  13 +--
 rust/macros/lib.rs   |   2 +-
 rust/uapi/lib.rs |   1 +
 scripts/Kconfig.include  |   6 +
 scripts/Makefile.compiler|   4 +
 scripts/rust_is_available.sh |  33 +++---
 scripts/rust_is_available_bindgen_0_66.h |   2 +
 scripts/rust_is_available_test.py|  59 ++
 scripts/rustc-version.sh |  52 +
 16 files changed, 274 insertions(+), 108 deletions(-)
 create mode 100644 scripts/rust_is_available_bindgen_0_66.h
 create mode 100755 scripts/rustc-version.sh


base-commit: fc6e66f4696b63b8a2645a2bcea407cb04bd0666
--
2.45.2

[PATCH v2 06/13] rust: start supporting several compiler versions

[Miguel Ojeda]

It is time to start supporting several Rust compiler versions and thus
establish a minimum Rust version.

We may still want to upgrade the minimum sometimes in the beginning since
there may be important features coming into the language that improve
how we write code (e.g. field projections), which may or may not make
sense to support conditionally.

We will start with a window of two stable releases, and widen it over
time. Thus this patch does not move the current minimum (1.78.0), but
instead adds support for the recently released 1.79.0.

This should already be enough for kernel developers in distributions that
provide recent Rust compiler versions routinely, such as Arch Linux,
Debian Unstable (outside the freeze period), Fedora Linux, Gentoo
Linux (especially the testing channel), Nix (unstable) and openSUSE
Tumbleweed. See the documentation patch about it later in this series.

In addition, Rust for Linux is now being built-tested in Rust's pre-merge
CI [1]. That is, every change that is attempting to land into the Rust
compiler is tested against the kernel, and it is merged only if it passes
-- thanks to the Rust project for that!

Thus, with the pre-merge CI in place, both projects hope to avoid
unintentional changes to Rust that break the kernel. This means that,
in general, apart from intentional changes on their side (that we will
need to workaround conditionally on our side), the upcoming Rust compiler
versions should generally work.

For instance, currently, the beta (1.80.0) and nightly (1.81.0) branches
work as well.

Of course, the Rust for Linux CI job in the Rust toolchain may still need
to be temporarily disabled for different reasons, but the intention is
to help bring Rust for Linux into stable Rust.

Link: https://github.com/rust-lang/rust/pull/125209 [1]
Reviewed-by: Finn Behrens 
Tested-by: Benno Lossin 
Tested-by: Andreas Hindborg 
Signed-off-by: Miguel Ojeda 
---
v2:
  - Update suggested `rustup` command to just install `stable`. (Finn)
  - Update suggested command for installing manually the Rust standard
library sources with the version that `rustc` reports, rather than
the minimum (since now the user may have installed e.g. stable).

 Documentation/process/changes.rst  |  4 +---
 Documentation/rust/quick-start.rst | 15 +++
 scripts/rust_is_available.sh   |  8 
 scripts/rust_is_available_test.py  |  5 -
 4 files changed, 8 insertions(+), 24 deletions(-)

diff --git a/Documentation/process/changes.rst 
b/Documentation/process/changes.rst
index 5685d7bfe4d0..0d0b7120792b 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -88,9 +88,7 @@ docs on :ref:`Building Linux with Clang/LLVM `.
 Rust (optional)
 ---

-A particular version of the Rust toolchain is required. Newer versions may or
-may not work because the kernel depends on some unstable Rust features, for
-the moment.
+A recent version of the Rust compiler is required.

 Each Rust toolchain comes with several "components", some of which are required
 (like ``rustc``) and some that are optional. The ``rust-src`` component (which
diff --git a/Documentation/rust/quick-start.rst 
b/Documentation/rust/quick-start.rst
index ac2f16288458..89bbfde8c96c 100644
--- a/Documentation/rust/quick-start.rst
+++ b/Documentation/rust/quick-start.rst
@@ -36,16 +36,15 @@ if that is the case.
 rustc
 *

-A particular version of the Rust compiler is required. Newer versions may or
-may not work because, for the moment, the kernel depends on some unstable
-Rust features.
+A recent version of the Rust compiler is required.

 If ``rustup`` is being used, enter the kernel build directory (or use
-``--path=`` argument to the ``set`` sub-command) and run::
+``--path=`` argument to the ``set`` sub-command) and run,
+for instance::

-   rustup override set $(scripts/min-tool-version.sh rustc)
+   rustup override set stable

-This will configure your working directory to use the correct version of
+This will configure your working directory to use the given version of
 ``rustc`` without affecting your default toolchain.

 Note that the override applies to the current working directory (and its
@@ -72,9 +71,9 @@ version later on requires re-adding the component.
 Otherwise, if a standalone installer is used, the Rust source tree may be
 downloaded into the toolchain's installation folder::

-   curl -L 
"https://static.rust-lang.org/dist/rust-src-$(scripts/min-tool-version.sh 
rustc).tar.gz" |
+   curl -L "https://static.rust-lang.org/dist/rust-src-$(rustc --version | 
cut -d' ' -f2).tar.gz" |
tar -xzf - -C "$(rustc --print sysroot)/lib" \
-   "rust-src-$(scripts/min-tool-version.sh rustc)/rust-src/lib/" \
+   "rust-src-$(rustc --version | cut -d' ' -f2)/rust-src/lib/" \
--strip-components=3

 In this

Re: [PATCH v2 00/13] Support several Rust toolchain versions

[Miguel Ojeda]

On Tue, Jul 9, 2024 at 6:06 PM Miguel Ojeda  wrote:
>
> A few things improved here and there, and rebased on top of `rust-next`.
>
> The changelog is attached to each patch.
>
> I kept the `Tested-by`s since most of the changes are on documentation
> or comments, though I did remove them on the patch that changed the most
> just in case (even for that one, I think Benno's and Andreas' setup
> would not have made a difference).
>
> I plan to put this series into `rust-next` very soon so that it goes
> into the merge window.

Applied into `rust-next` -- thanks everyone!

Cheers,
Miguel