modpost: refactor error handling and clarify error/fatal difference
authorMasahiro Yamada <masahiroy@kernel.org>
Tue, 1 Dec 2020 10:34:15 +0000 (19:34 +0900)
committerMasahiro Yamada <masahiroy@kernel.org>
Mon, 21 Dec 2020 04:57:08 +0000 (13:57 +0900)
commit0fd3fbadd9a85e391828f3ef63ef1e96e2d2d752
tree105e87682552d219180cf12357bd690951157592
parentbc72d723ec6b75c53e935e819682c3e67b83e9c1
modpost: refactor error handling and clarify error/fatal difference

We have 3 log functions. fatal() is special because it lets modpost bail
out immediately. The difference between warn() and error() is the only
prefix parts ("WARNING:" vs "ERROR:").

In my understanding, the expected handling of error() is to propagate
the return code of the function to the exit code of modpost, as
check_exports() etc. already does. This is a good manner in general
because we should display as many error messages as possible in a
single run of modpost.

What is annoying about fatal() is that it kills modpost at the first
error. People would need to run Kbuild again and again until they fix
all errors.

But, unfortunately, people tend to do:
"This case should not be allowed. Let's replace warn() with fatal()."

One of the reasons is probably it is tedious to manually hoist the error
code to the main() function.

This commit refactors error() so any single call for it automatically
makes modpost return the error code.

I also added comments in modpost.h for warn(), error(), and fatal().

Please use fatal() only when you have a strong reason to do so.
For example:

  - Memory shortage (i.e. malloc() etc. has failed)
  - The ELF file is broken, and there is no point to continue parsing
  - Something really odd has happened

For general coding errors, please use error().

Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Quentin Perret <qperret@google.com>
scripts/mod/modpost.c
scripts/mod/modpost.h