The kernel size changes due to many factors, such as compiler
version, configuration, and the build environment. This makes
size comparison figures irrelevant to reader's setup.
Remove these figures and describe the effects of page owner
to the kernel size in general instead.
Thanks for Jonathan Corbet, Bagas Sanjaya and Mike Rapoport's
constructive suggestions.
Signed-off-by: Yixuan Cao <caoyixuan2019@email.szu.edu.cn>
Link: https://lore.kernel.org/r/20221005145525.10359-1-caoyixuan2019@email.szu.edu.cn
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Since a patch set in my translation devicetree
introduce some build warnings:
Warning: Documentation/translations/zh_CN/devicetree/changesets.rst
references a file that doesn't exist:
Documentation/Devicetree/changesets.rst
...
Change the first letter of Devicetree to lowercase.
Fixes: 9485acfded ("docs/zh_CN: add dt kernel-api translation")
Fixes: f773455ce5 ("docs/zh_CN: add dt overlay-notes translation")
Fixes: 5e38432db8 ("docs/zh_CN: add dt dynamic-resolution-notes translation")
Fixes: 330f5a3005 ("docs/zh_CN: add dt changesets translation")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Yanteng Si <siyanteng@loongson.cn>
Reviewed-by: Wu XiangCheng <bobwxc@email.cn>
Link: https://lore.kernel.org/r/20221008094139.314151-1-siyanteng@loongson.cn
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
checkpatch does not point out that VM_BUG_ON() and friends should be
avoided, however, Linus notes:
VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally
no different, the only difference is "we can make the code smaller
because these are less important". [1]
So let's warn on VM_BUG_ON() and other BUG variants as well. While at it,
make it clearer that the kernel really shouldn't be crashed.
As there are some subsystem BUG macros that actually don't end up crashing
the kernel -- for example, KVM_BUG_ON() -- exclude these manually.
[1] https://lore.kernel.org/r/CAHk-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20220923113426.52871-3-david@redhat.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Linus notes [1] that the introduction of new code that uses VM_BUG_ON()
is just as bad as BUG_ON(), because it will crash the kernel on
distributions that enable CONFIG_DEBUG_VM (like Fedora):
VM_BUG_ON() has the exact same semantics as BUG_ON. It is literally
no different, the only difference is "we can make the code smaller
because these are less important". [2]
This resulted in a more generic discussion about usage of BUG() and
friends. While there might be corner cases that still deserve a BUG_ON(),
most BUG_ON() cases should simply use WARN_ON_ONCE() and implement a
recovery path if reasonable:
The only possible case where BUG_ON can validly be used is "I have
some fundamental data corruption and cannot possibly return an
error". [2]
As a very good approximation is the general rule:
"absolutely no new BUG_ON() calls _ever_" [2]
... not even if something really shouldn't ever happen and is merely for
documenting that an invariant always has to hold. However, there are sill
exceptions where BUG_ON() may be used:
If you have a "this is major internal corruption, there's no way we can
continue", then BUG_ON() is appropriate. [3]
There is only one good BUG_ON():
Now, that said, there is one very valid sub-form of BUG_ON():
BUILD_BUG_ON() is absolutely 100% fine. [2]
While WARN will also crash the machine with panic_on_warn set, that's
exactly to be expected:
So we have two very different cases: the "virtual machine with good
logging where a dead machine is fine" - use 'panic_on_warn'. And
the actual real hardware with real drivers, running real loads by
users. [4]
The basic idea is that warnings will similarly get reported by users
and be found during testing. However, in contrast to a BUG(), there is a
way to actually influence the expected behavior (e.g., panic_on_warn)
and to eventually keep the machine alive to extract some debug info.
Ingo notes that not all WARN_ON_ONCE cases need recovery. If we don't ever
expect this code to trigger in any case, recovery code is not really
helpful.
I'd prefer to keep all these warnings 'simple' - i.e. no attempted
recovery & control flow, unless we ever expect these to trigger.
[5]
There have been different rules floating around that were never properly
documented. Let's try to clarify.
[1] https://lkml.kernel.org/r/CAHk-=wiEAH+ojSpAgx_Ep=NKPWHU8AdO3V56BXcCsU97oYJ1EA@mail.gmail.com
[2] https://lore.kernel.org/r/CAHk-=wg40EAZofO16Eviaj7mfqDhZ2gVEbvfsMf6gYzspRjYvw@mail.gmail.com
[3] https://lkml.kernel.org/r/CAHk-=wit-DmhMfQErY29JSPjFgebx_Ld+pnerc4J2Ag990WwAA@mail.gmail.com
[4] https://lore.kernel.org/r/CAHk-=wgF7K2gSSpy=m_=K3Nov4zaceUX9puQf1TjkTJLA2XC_g@mail.gmail.com
[5] https://lore.kernel.org/r/YwIW+mVeZoTOxn%2F4@gmail.com
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Link: https://lore.kernel.org/r/20220923113426.52871-2-david@redhat.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Now that building html docs with math expressions does not need texlive
packages, remove the note on the requirement in the "Sphinx Install"
section.
Instead, add sections of "Math Expressions in HTML" and "Choice of Math
Renderer".
Describe the effect of setting SPHINX_IMGMATH in the latter section.
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
Cc: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/a67e3279-6bc7-ee2c-2b49-9275252460b0@gmail.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Bring the description on when to use the Reported-by: tag found in
Documentation/process/5.Posting.rst more in line with the description in
Documentation/process/submitting-patches.rst: before this change the two
were contradicting each other, as the latter is way more permissive and
only states '[...] if the bug was reported in private, then ask for
permission first before using the Reported-by tag.'
Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Link: https://lore.kernel.org/r/2fc7162dfb76e04da5ea903c9c170d913e735dad.1664372256.git.linux@leemhuis.info
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The top-level index.rst file is the entry point for the kernel's
documentation, especially for readers of the HTML output. It is currently
a mess containing everything we thought to throw in there. Firefox says it
would require 26 pages of paper to print it. That is not a user-friendly
introduction.
This series aims to improve our documentation entry point with a focus on
rewriting index.rst. The result is, IMO, simpler and more approachable.
For anybody who wants to see the rendered results without building the
docs, have a look at:
https://static.lwn.net/kerneldoc/
This time around I've rendered the pages using the "Read The Docs" theme,
since that's what everybody will get by default. That theme ignores the
directives regarding the left column, so the results are not as good there.
I have a series proposing a default-theme change in the works, but that's a
separate topic.
This is only a beginning; I think this kind of organizational effort has to
be pushed down into the lower layers of the docs tree itself. But one has
to start somewhere.
These files describe part of the core API, but have never been converted to
RST due to ... let's say local oppposition. So, create a set of
special-purpose wrappers to ..include these files into a separate page so
that they can be a part of the htmldocs build. Then link them into the
core-api manual and remove them from the "staging" dumping ground.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Reviewed-by: David Vernet <void@manifault.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20220927160559.97154-7-corbet@lwn.net
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
The front page is the entry point to the documentation, especially for
people who read it online. It's a big mess of everything we could think to
toss into it. Rewrite the page with an eye toward simplicity and making it
easy for readers to get going toward what they really want to find.
This is only a beginning, but it makes our docs more approachable than
before.
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: David Vernet <void@manifault.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20220927160559.97154-3-corbet@lwn.net
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
In Fedora 36, cross-compiling an allmodconfig configuration
for other architectures on x86 fails with this problem:
In file included from ../scripts/gcc-plugins/gcc-common.h:95,
from ../scripts/gcc-plugins/latent_entropy_plugin.c:78:
/usr/lib/gcc/aarch64-linux-gnu/12/plugin/include/builtins.h:23:10: fatal
error: mpc.h: No such file or directory
23 | #include <mpc.h>
| ^~~~~~~
compilation terminated.
In that distro, that header file is available in the separate
libmpc-devel package.
Although future versions of Fedora might correctly mark
that dependency, mention this additional package.
To help detect such problems ahead of time, describe the
gcc -print-file-name=plugin
command that is used by scripts/gcc-plugins/Kconfig to detect
plugins [1].
[1] https://lore.kernel.org/lkml/CAHk-=wjjiYjCp61gdAMpDOsUBU-A2hFFKJoVx5VAC7yV4K6WYg@xxxxxxxxxxxxxx/
Fixes: 43e96ef8b7 ("docs/core-api: Add Fedora instructions for GCC plugins");
Signed-off-by: Robert Elliott <elliott@hpe.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220827193836.2582079-1-elliott@hpe.com
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
