Akira Yokosawa [Tue, 29 Mar 2022 06:07:02 +0000 (15:07 +0900)]
docs: sphinx/requirements: Limit jinja2<3.1
jinja2 release 3.1.0 (March 24, 2022) broke Sphinx<4.0.
This looks like the result of deprecating Python 3.6.
It has been tested against Sphinx 4.3.0 and later.
Setting an upper limit of <3.1 to junja2 can unbreak Sphinx<4.0
including Sphinx 2.4.4.
The Architecture chapter of the KUnit documentation tried to include
copies of the kernel-doc for a couple of things, despite these already
existing in the API documentation. This lead to some warnings:
architecture:31: ./include/kunit/test.h:3: WARNING: Duplicate C declaration, also defined at dev-tools/kunit/api/test:66.
Declaration is '.. c:struct:: kunit_case'.
architecture:163: ./include/kunit/test.h:1217: WARNING: Duplicate C declaration, also defined at dev-tools/kunit/api/test:1217.
Declaration is '.. c:macro:: KUNIT_ARRAY_PARAM'.
architecture.rst:3: WARNING: Duplicate C declaration, also defined at dev-tools/kunit/api/test:66.
Declaration is '.. c:struct:: kunit_case'.
architecture.rst:1217: WARNING: Duplicate C declaration, also defined at dev-tools/kunit/api/test:1217.
Declaration is '.. c:macro:: KUNIT_ARRAY_PARAM'.
Get rid of these, and cleanup the mentions of the struct and macro in
question so that sphinx generates a link to the existing copy of the
documentation in the api/test document.
The files included by kernel-include should be added as build
dependencies, in order for sphinx-build to rebuild the corresponding
docs if any changes at the included file happens.
Ensure that Sphinx-build will handle the files parsed by
get_abi.pl as dependencies. This way, if they are touched,
the ABI output will be regenerated.
scripts/get_feat.pl: allow output the parsed file names
Such output could be helpful while debugging it, but its main
goal is to tell kernel_feat.py about what files were used
by the script. Thie way, kernel_feat.py can add those as
documentation dependencies.
Akira Yokosawa [Sat, 26 Mar 2022 07:48:39 +0000 (16:48 +0900)]
docs: kfigure.py: Don't warn of missing PDF converter in 'make htmldocs'
SVG -> PDF conversion is not required in "make htmldocs".
It is pointless to always warn of a missing converter.
Demote the log message in setupTools() to verbose.
For "make pdfdocs" (or "make latexdocs"), promote the dynamic
message of "include SVG raw" to a warn.
Expand the message and recommend installing Inkscape or
ImageMagick.
Fixes: 32707208fefd ("docs: sphinx/kfigure.py: Use inkscape(1) for SVG -> PDF conversion") Signed-off-by: Akira Yokosawa <akiyks@gmail.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: linux-doc@vger.kernel.org Acked-by: Mauro Carvalho Chehab <mchehab@kernel.org> Link: https://lore.kernel.org/r/c80e1481-10d4-7151-fe59-e846259eb0d4@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Documentation: Fix duplicate statement about raw_spinlock_t type
Unless it was duplicate on purpose, to emphasize that a raw_spinlock_t
is always a spinning lock regardless of PREEMPT_RT or kernel config,
it's a bit odd that this text is duplicate. So, this patch just clean
it up, keeping the consistency with the other sections of the text.
Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: dc92152fd217 ("Documentation: Add lock ordering and nesting documentation") Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20220321144133.49804-1-gpiccoli@igalia.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Wan Jiabing [Fri, 4 Mar 2022 10:03:15 +0000 (18:03 +0800)]
docs: serial: fix a reference file name in driver.rst
Fix the following 'make refcheckdocs' warning:
Warning: Documentation/driver-api/serial/driver.rst references a file
that doesn't exist: Documentation/driver-api/serial/tty.rst
It is not obvious from the documentation that using the "port" channel
for the console requires telnetd to be installed (see port_connection()
in arch/um/drivers/port_user.c). Mention this, and the fact that UML
will not boot until a client connects.
Bagas Sanjaya [Mon, 7 Mar 2022 06:33:41 +0000 (13:33 +0700)]
Documentation: describe how to apply incremental stable patches
The applying patches document
(Documentation/process/applying-patches.rst) mentions incremental stable
patches, but there is no example of how to apply them. Describe the
process.
While at it, remove note about incremental patches and move the external
link of 5.x.y incremental patches to "Where can I download patches?"
section.
Kees Cook [Fri, 4 Mar 2022 18:14:18 +0000 (10:14 -0800)]
Documentation/process: Add Researcher Guidelines
As a follow-up to the UMN incident[1], the TAB took the responsibility
to document Researcher Guidelines so there would be a common place to
point for describing our expectations as a developer community.
Document best practices researchers should follow to participate
successfully with the Linux developer community.
docs: reporting-issues.rst: link new document about regressions
Make Documentation/admin-guide/reporting-issues.rst point to the newly
created document about regressions
(Documentation/admin-guide/regressions-regressions.rst). This allows to
shorten a few explanations the new document describes better and in more
detail.
While at it move the copyright hint to the end of the file and remove
quotes around links to other places in the documentation. Both issues
came up during the review of the new documents about regressions.
docs: *-regressions.rst: explain how quickly issues should be handled
Add a section with a few rules of thumb about how
quickly developers should address regressions to
Documentation/process/handling-regressions.rst; additionally,
add a short paragraph about this to the companion document
Documentation/admin-guide/reporting-regressions.rst as well.
The rules of thumb were written after studying the quotes from Linus
found in handling-regressions.rst and especially influenced by
statements like "Users are literally the _only_ thing that matters" and
"without users, your program is not a program, it's a pointless piece of
code that you might as well throw away". The author interpreted those in
perspective to how the various Linux kernel series are maintained
currently and what those practices might mean for users running into a
regression on a small or big kernel update.
That for example lead to the paragraph starting with "Aim to get fixes
for regressions mainlined within one week after identifying the culprit,
if the regression was introduced in a stable/longterm release or the
devel cycle for the latest mainline release". Some might see this as
pretty high bar, but on the other hand something like that is needed to
not leave users out in the cold for too long -- which can quickly happen
when updating to the latest stable series, as the previous one is
normally stamped "End of Life" about three or four weeks after a new
mainline release. This makes a lot of users switch during this
timeframe. Any of them thus risk running into regressions not promptly
fixed; even worse, once the previous stable series is EOLed for real,
users that face a regression might be left with only three options:
(1) continue running an outdated and thus potentially insecure kernel
version from an abandoned stable series
(2) run the kernel with the regression
(3) downgrade to an earlier longterm series still supported
This is better avoided, as (1) puts users and their data in danger, (2)
will only be possible if it's a minor regression that doesn't interfere
with booting or serious usage, and (3) might be regression itself or
impossible on the particular machine, as the users might require drivers
or features only introduced after the latest longterm series branched
of.
In the end this lead to the aforementioned "Aim to fix regression within
one week" part. It's also the reason for the "Try to resolve any
regressions introduced in the current development cycle before its
end.".
Create two documents explaining various aspects around regression
handling and tracking; one is aimed at users, the other targets
developers.
The texts among others describes the first rule of Linux kernel
development and what it means in practice. They also explain what a
regression actually is and how to report one properly.
Both texts additionally provide a brief introduction to the bot the
kernel's regression tracker uses to facilitate the work, but mention the
use is optional.
To sum things up, provide a few quotes from Linus in the document for
developers to show how serious we take regressions.
Jonathan Corbet [Thu, 24 Feb 2022 19:35:07 +0000 (12:35 -0700)]
docs: fix RST error in vm/page_owner.rst
Commit d090447f6c35 ("tools/vm/page_owner_sort.c: count and sort by mem")
added a literal text block without the necessary markup, leading to these
warnings in the docs build:
Akira Yokosawa [Fri, 18 Feb 2022 14:26:34 +0000 (23:26 +0900)]
Reword note on missing CJK fonts
Use past tense as the fonts can be installed after the fact.
Add suggestion to install "Noto Sans CJK" and "Noto Serif CJK"
font families. ("Noto Serif CJK" is optional.)
Akira Yokosawa [Fri, 18 Feb 2022 14:13:41 +0000 (23:13 +0900)]
docs: kerneldoc-preamble.sty: Expand comments in LaTeX code
Expand comments in LaTeX code and mention some of important points
told in changelogs of conf.py changes.
Hopefully they can help future contributors in this area.
Akira Yokosawa [Fri, 18 Feb 2022 14:11:17 +0000 (23:11 +0900)]
docs: pdfdocs: Pull LaTeX preamble part out of conf.py
Quote from Jon's remark [1]:
I do notice that Documentation/conf.py is getting large and
unapproachable. At some future point, it might be nice to pull
all of the latex stuff out into a separate file where it won't
scare people who stumble into it by accident.
Pull LaTeX preamble settings added since commit 6f2a5b35bee8 ("docs:
conf.py: adjust the LaTeX document output") out into
sphinx/kerneldoc-preamble.sty.
It will be copied to the build directory by the added
"latex_additional_files" setting in conf.py.
As a bonus, LaTeX/TeX code can be maintained without escaping backslashes.
To compensate the loss of change history in sphinx/kerneldoc-preamble.sty,
here is a list of changes made in conf.py:
- 9966481fbd71 ("docs: Activate exCJK only in CJK chapters")
- b38fac965b70 ("docs: pdfdocs: Prevent column squeezing by tabulary")
- 123bf42c73d5 ("docs: pdfdocs: Refactor config for CJK document")
- cbbd5dfdbcd2 ("docs: pdfdocs: Add CJK-language-specific font settings")
- 1c3f8e4d0731 ("docs: pdfdocs: Choose Serif font as CJK mainfont if possible")
- b94fcd8c79be ("docs: pdfdocs: Preserve inter-phrase space in Korean translations")
- dac183fa8d3f ("docs: pdfdocs: One-half spacing for CJK translations")
- c7d34c131fc2 ("docs: pdfdocs: Permit AutoFakeSlant for CJK fonts")
- d20edb909ef4 ("docs: pdfdocs: Teach xeCJK about character classes of quotation marks")
- f656087e2e33 ("docs: pdfdocs: Fix typo in CJK-language specific font settings")
- e615474700eb ("docs: pdfdocs: Adjust \headheight for fancyhdr")
- fa4f779794df ("docs: pdfdocs: Tweak width params of TOC")
- 9e3f3cf02fdd ("docs: pdfdocs: Switch default CJK font to KR variants")
- 32ec19662cf7 ("docs: pdfdocs: Enable CJKspace in TOC for Korean titles")
- b60dc7ef1f09 ("docs/translations: Skip CJK contents if suitable fonts not found")
- 7af670814048 ("docs: pdfdocs: Move CJK monospace font setting to main conf.py")
Akira Yokosawa [Thu, 24 Feb 2022 13:02:46 +0000 (22:02 +0900)]
docs: scripts/kernel-doc: Detect absence of FILE arg
Currently, when there is no FILE argument following a switch such
as -man, -rst, or -none, kernel-doc exits with a warning from perl
(long msg folded):
Use of uninitialized value $ARGV[0] in pattern match (m//)
at ./scripts/kernel-doc line 438.
, which is unhelpful.
Improve the behavior by adding a check at the bottom of parsing
loop.
If the argument is absent, display help text and exit with
the code of 1 (via usage()).
Tomasz Warniełło [Fri, 18 Feb 2022 18:16:27 +0000 (19:16 +0100)]
scripts: kernel-doc: Drop obsolete comments
What for? To improve the script maintainability.
1. License
As stated by Jonathan Corbet in the reply to my version 1, the SPDX line
is enough.
2. The to-do list comment
As suggested by Jonathan Corbet in reply to my version 3, this section
doesn't need to be transitioned. And so it is removed for clarity.
3. The historical changelog comments
As suggested by Jonathan Corbet in a reply to v3, this section can go.
I wanted to keep it, but since it doesn't contain copyright notices,
let's just have it clean and simple.
4. The "format of comments" comment block
As suggested by Jani Nikula in a reply to my first version of this
transformation, Documentation/doc-guide/kernel-doc.rst can serve as the
information hub for comment formatting. The section DESCRIPTION already
points there, so the original comment block can just be removed.
Suggested-by: Jonathan Corbet <corbet@lwn.net> Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Tomasz Warniełło <tomasz.warniello@gmail.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Disliked-by: Akira Yokosawa <akiyks@gmail.com> Link: https://lore.kernel.org/r/20220218181628.1411551-11-tomasz.warniello@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Tomasz Warniełło [Fri, 18 Feb 2022 18:16:23 +0000 (19:16 +0100)]
scripts: kernel-doc: Translate the "Output selection" subsection of OPTIONS
Aim: unified POD, user more satisfied, script better structured
The plurals in -function and -nosymbol are corrected to singulars.
That's how the script works now. I think this describes the syntax better.
The plurar suggests multiple FILE arguments might be possible. So this
seems more coherent.
Other notes:
- paragraphing correction
- article correction
Signed-off-by: Tomasz Warniełło <tomasz.warniello@gmail.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Disliked-by: Akira Yokosawa <akiyks@gmail.com> Link: https://lore.kernel.org/r/20220218181628.1411551-7-tomasz.warniello@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Tomasz Warniełło [Fri, 18 Feb 2022 18:16:20 +0000 (19:16 +0100)]
scripts: kernel-doc: Translate the DESCRIPTION section
Transition the description section into POD. This is one of the standard
documentation sections. This adjustment makes the section available for
POD and makes it look better.
Notes:
- an article addition
- paragraphing correction
Signed-off-by: Tomasz Warniełło <tomasz.warniello@gmail.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Disliked-by: Akira Yokosawa <akiyks@gmail.com> Link: https://lore.kernel.org/r/20220218181628.1411551-4-tomasz.warniello@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Tomasz Warniełło [Fri, 18 Feb 2022 18:16:18 +0000 (19:16 +0100)]
scripts: kernel-doc: Add the basic POD sections
The NAME section provides the doc title, while SYNOPSIS contains
the basic syntax and usage description, which will be printed
in the help document and in the error output produced on wrong script
usage.
The rationale is to give users simple and succinct enlightment,
at the same time structuring the script internally for the maintainers.
In the synopsis, Rst-only options are grouped around rst, and the rest is
arranged as in the OPTIONS subsections (yet to be translated into POD,
check at the end of the series).
The third of the basic sections, DESCRIPTION, is added separately.
Signed-off-by: Tomasz Warniełło <tomasz.warniello@gmail.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Disliked-by: Akira Yokosawa <akiyks@gmail.com> Link: https://lore.kernel.org/r/20220218181628.1411551-2-tomasz.warniello@gmail.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Jonathan Corbet [Thu, 17 Feb 2022 16:33:10 +0000 (09:33 -0700)]
Merge branch 'pdf' into docs-next
Akira says:
This series resolves issues listed below:
1. Some of chapter and section counts in Table of Contents (TOC) in
large PDF docs collide with chapter/section titles, e.g., Chapters 10,
11, 12, and 13 and Section 10.10 in userspace-api.pdf.
2. In docs of more than 99 pages, page counts in TOC are not aligned
properly when maxdepth >= 2 is specified in toctree, e.g., Chapters 10,
12, and 13 in userspace-api.pdf
3. In TOC of Latin-script docs, quotation and apostrophe symbols look too
wide, e.g., Section 2.2 in userspace-api.pdf.
4. In TOC of translations, Korean chapter titles lose inter-phrase spaces.
5. On systems without "Noto Sans CJK" fonts, CJK chapters in translations
results in full of "TOFU" boxes, with a long build time and a large
log file containing lots of missing-font warnings.
6. In translations.pdf built by "make pdfdocs", ascii-art diagrams in CJK
are not aligned properly.
Akira Yokosawa [Tue, 1 Feb 2022 00:05:40 +0000 (09:05 +0900)]
docs: pdfdocs: Move CJK monospace font setting to main conf.py
As LaTeX macros for CJK font settings can have Latin-script font
settings as well, settings under Documentation/translations/ can
be moved to the main conf.py.
By this change, translations.pdf built by top-level "make pdfdocs"
can have properly aligned ascii-art diagrams except for Korean
ones.
For the reason of remaining misalignment in Korean diagrams, see
changelog of commit 578f3c7c7365 ("docs: pdfdocs: Add conf.py
local to translations for ascii-art alignment").
Akira Yokosawa [Tue, 1 Feb 2022 00:04:40 +0000 (09:04 +0900)]
docs/translations: Skip CJK contents if suitable fonts not found
On systems without "Noto Sans CJK" fonts, CJK chapters in
translations.pdf are full of "TOFU" boxes, with a long build time and
a large log file containing lots of missing-font warnings.
Avoid such waste of time and resources by skipping CJK chapters when
CJK fonts are not available.
To skip whole chapters, change the definition of
\kerneldocBegin{SC|TC|KR|JP} commands so that they can have an argument
to be ignored.
This works as far as the argument (#1) is not used in the command.
In place of skipped contents, put a note on skipped contents at the
beginning of the PDF.
Change the call sites in index.rst of CJK translations accordingly.
When CJK fonts are available, existing command definitions with
no argument just work. LaTeX engine will see additional pairs of
"{" and "}", which add a level of grouping without having any effect
on typesetting.
Akira Yokosawa [Tue, 1 Feb 2022 00:02:14 +0000 (09:02 +0900)]
docs: pdfdocs: Switch default CJK font to KR variants
xeCJK is enabled in Table of Contents (TOC) so that translations.pdf
built by top-level "make pdfdocs" can have its TOC typeset properly.
This causes quotation marks and apostrophe symbols appear too wide in
Latin-script docs.
This is because (1) Sphinx converts ASCII symbols into multi-byte
UTF-8 ones in LaTeX and (2) in the SC variant of "Noto CJK" font
families, those UTF-8 symbols have full-width glyph.
The KR variant of the font families has half-width glyph for those
symbols and TOC pages should look nicer when it is used instead.
Switch the default CJK font families to the KR variant and teach
xeCJK of those symbols' widths.
To compensate the switch, teach xeCJK of the width in the SC and
TC variants.
Akira Yokosawa [Mon, 31 Jan 2022 23:59:58 +0000 (08:59 +0900)]
docs: pdfdocs: Tweak width params of TOC
Sphinx has its own set of width parameters of Table of Contents (TOC)
for LaTeX defined in its class definition of sphinxmanual.cls.
It also inherits parameters for chapter entries from report.cls of
original LaTeX base.
However, they are optimized assuming small documents with tens of
pages and chapters/sections of less than 10.
To cope with some of kernel-doc documents with more than 1000
pages and several tens of chapters/sections, definitions of those
parameters need to be adjusted.
Unfortunately, those parameters are hard coded in the class
definitions and need low-level LaTeX coding tricks to redefine.
As Sphinx 1.7.9 does not have \sphinxtableofcontentshook,
which defines those parameters in later Sphinx versions,
for compatibility with both pre-1.8 and later Sphinx versions,
empty the hook altogether and redefine \@pnumwidth, \l@chapter,
\l@section, and \@subsection commands originally defined in
report.cls.
Summary of parameter changes:
Width of page number (\@pnumwidth): 1.55em -> 2.7em
Width of chapter number: 1.5em -> 1.8em
Indent of section number: 1.5em -> 1.8em
Width of section number: 2.6em -> 3.2em
Indent of subsection number: 4.1em -> 5em
Width of subsection number: 3.5em -> 4.3em
Notes:
1. Parameters for subsection become relevant only when
":maxdepth: 3" is specified under "toctree::" (e.g., RCU/index.rst).
They can hold subsection numbers up to 5 digits such as "18.7.13"
(in RCU.pdf).
2. Number of chapters in driver-api.pdf is getting closer to 100.
When it reaches 100, another set of tweaks will be necessary.
3. The low-level LaTeX trick is mentioned in "Unofficial LaTeX2e
reference manual" at:
http://latexref.xyz/Table-of-contents-etc_002e.html
Akira Yokosawa [Thu, 10 Feb 2022 01:26:53 +0000 (10:26 +0900)]
docs: Makefile: Add -no-shell-escape option to LATEXOPTS
It turns out that LaTeX enables \write18, which allows (some) shell
commands to be executed from the document source, by default. This the
often-seen warning during a pdfdocs build:
restricted \write18 enabled
That is a potential security problem and is entirely unnecessary; nothing
in the kernel PDF docs build needs that capability. So disable \write18
explicitly.
Jonathan Corbet [Thu, 10 Feb 2022 00:29:05 +0000 (17:29 -0700)]
Merge branch 'pdf-conversion' into docs-next
PDF-generation improvements from Akira Yokasawa; Akira says:
This patch set improves conversions of DOT -> PDF and SVG -> PDF
for PDF docs.
* DOT -> PDF conversion
Current scheme uses "dot -Tpdf" (of graphviz).
Cons:
- openSUSE's dot(1) does not support -Tpdf.
- Other distro's dot(1) generates PDFs with unnecessarily wide
margins for inclusion into LaTeX docs.
Patch 1/4 changes the route to the following two steps:
1. DOT -> SVG by "dot -Tsvg"
2. SVG -> PDF by "rsvg-convert -f pdf" with fallback to convert(1)
Pros:
- Improved portability across distros
- Less space around graphs in final PDF documents
Con:
- On systems without rsvg-convert, generated PDF will be of raster
image.
Patch 2/4 avoids raster-image PDF by using "dot -Tpdf" on systems where
the option is available.
* SVG -> PDF conversion
Current scheme uses convert(1) (of ImageMagick)
Cons:
- Generated PDFs are of raster image. Some of them look blurry.
- Raster images tend to be large in size.
- convert(1) delegates SVG decoding to rsvg-convert(1).
It doesn't cover full range of Inkscape-specific SVG features
and fails to convert some of SVG figures properly.
Improper conversions are observed with SVGs listed below (incomplete,
conversion quality depends on the version of rsvg-convert):
- Documentation/userspace-api/media/v4l/selection.svg
- Documentation/userspace-api/media/v4l/vbi_525.svg
- Documentation/userspace-api/media/v4l/vbi_625.svg
- Documentation/userspace-api/media/v4l/vbi_hsync.svg
- Documentation/admin-guide/blockdev/drbd/DRBD-8.3-data-packets.svg
- Documentation/admin-guide/blockdev/drbd/DRBD-data-packages.svg
If you have Inkscape installed as well, convert(1) delegates SVG
decoding to inkscape(1) rather than to rsvg-convert(1) and SVGs listed
above can be rendered properly.
So if Inkscape is required for converting those SVGs properly, why not
use it directly in the first place?
Patches 3/4 and 4/4 add code to utilize inkscape(1) for SVG -> PDF
conversion when it is available. They don't modify any existing
requirements for kernel-doc.
Patch 3/4 adds the alternative route of SVG -> PDF conversion by
inkscape(1).
Patch 4/4 delegates warning messages from inkscape(1) to kernellog.verbose
as they are likely harmless in command-line uses.
Pros:
- Generated PDFs are of vector graphics.
- Vector graphics tends to be smaller in size and looks nicer when
zoomed in.
- SVGs drawn by Inkscape are fully supported.
On systems without Inkscape, no regression is expected by these two
patches.
Akira Yokosawa [Wed, 29 Dec 2021 11:45:29 +0000 (20:45 +0900)]
docs: sphinx/kfigure.py: Add check of 'dot -Tpdf'
To prevent any regression on existing build systems, limit the
fallback of converting DOT -> raster PDF only when both of the
following conditions are met.
o dot(1) doesn't support -Tpdf
o rsvg-convert(1) is not found
While we are here, add kernellog.verbose messages related to
rsvg-convert, 'dot -Tpdf', and 'dot -Tsvg' commands.
Akira Yokosawa [Wed, 29 Dec 2021 11:44:19 +0000 (20:44 +0900)]
docs: sphinx/kfigure.py: Use rsvg-convert(1) for DOT -> PDF conversion
On openSUSE, dot(1) command does not support direct PDF output.
On other distros, generated PDF images have unnecessarily wide margins,
especially for small graphs.
By using dot(1) for DOT -> SVG, then rsvg-convert(1) for SVG -> PDF,
more optimal PDF images can be obtained, with the bonus of improved
portability across various distros.
Add rules in kfigure.py so that the above mentioned route is taken
when rsvg-convert(1) is available.
Note that rsvg-convert(1) is recommended by sphinx_pre_install.
So it is most likely that existing systems for building pdfdocs have
rsvg-convert(1) installed.
Note:
SVG features supported by rsvg-convert(1) vary depending on its
version and distro config.
For example, the one found on Ubuntu Bionic (version 2.40.20) does
poor job in rendering some of SVG files drawn by Inkscape.
SVG files generated by dot(1) are converted nicely even with such
old versions of rsvg-convert.
So this change does not affect the quality of such figures in any
way.
Andy Shevchenko [Thu, 27 Jan 2022 16:32:58 +0000 (18:32 +0200)]
docs: process: submitting-patches: Clarify the Reported-by usage
It's unclear from "Submitting Patches" documentation that Reported-by
is not supposed to be used against new features. (It's more clear
in the section 5.4 "Patch formatting and changelogs" of the "A guide
to the Kernel Development Process", where it suggests that change
should fix something existing in the kernel. Clarify the Reported-by
usage in the "Submitting Patches".
Update zh_CN/accounting/delay-accounting.rst.
The document modification has been merged which refers to the following link:
https://lore.kernel.org/all/1639583021-92977-1-git-send-email-wang.yong12@zte.com.cn/
Documentation: core-api: entry: Add comments about nesting
The topic of nesting and reentrancy in the context of early entry code
hasn't been addressed so far. So do it.
Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com> Reviewed-by: Frederic Weisbecker <frederic@kernel.org> Reviewed-by: Paul E. McKenney <paulmck@kernel.org> Link: https://lore.kernel.org/r/20220110105044.94423-2-nsaenzju@redhat.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Thomas Gleixner [Mon, 10 Jan 2022 10:50:43 +0000 (11:50 +0100)]
Documentation: Fill the gaps about entry/noinstr constraints
The entry/exit handling for exceptions, interrupts, syscalls and KVM is
not really documented except for some comments.
Fill the gaps.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de Co-developed-by: Nicolas Saenz Julienne <nsaenzju@redhat.com> Signed-off-by: Nicolas Saenz Julienne <nsaenzju@redhat.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
----
Changes since v3:
- s/nointr/noinstr/
Changes since v2:
- No big content changes, just style corrections, so it should be
pretty clean at this stage. In the light of this, I kept Mark's
Reviewed-by.
- Paul's style and paragraph re-writes
- Randy's style comments
- Add links to transition type sections
Jonathan Corbet [Fri, 21 Jan 2022 00:00:33 +0000 (17:00 -0700)]
docs: Hook the RTLA documents into the kernel docs build
The RTLA documents were added to Documentation/ but never hooked into the
rest of the docs build, leading to a bunch of warnings like:
Documentation/tools/rtla/rtla-osnoise.rst: WARNING: document isn't included in any toctree
Add some basic glue to wire these documents into the build so that they are
available with the rest of the rendered docs. No attempt has been made to
turn the RTLA docs into proper RST files rather than warmed-over man pages;
that is an exercise for the future.
Fixes: 39987c9be4bf ("rtla: Add Documentation") Acked-by: Daniel Bristot de Oliveira <bristot@kernel.org> Acked-by: Steven Rostedt (Google) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/877dau555q.fsf@meer.lwn.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Linus Torvalds [Sun, 23 Jan 2022 06:14:21 +0000 (08:14 +0200)]
Merge tag 'perf-tools-for-v5.17-2022-01-22' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux
Pull more perf tools updates from Arnaldo Carvalho de Melo:
- Fix printing 'phys_addr' in 'perf script'.
- Fix failure to add events with 'perf probe' in ppc64 due to not
removing leading dot (ppc64 ABIv1).
- Fix cpu_map__item() python binding building.
- Support event alias in form foo-bar-baz, add pmu-events and
parse-event tests for it.
- No need to setup affinities when starting a workload or attaching to
a pid.
- Use path__join() to compose a path instead of ad-hoc snprintf()
equivalent.
- Override attr->sample_period for non-libpfm4 events.
- Use libperf cpumap APIs instead of accessing the internal state
directly.
- Sync x86 arch prctl headers and files changed by the new
set_mempolicy_home_node syscall with the kernel sources.
- Remove duplicate include in cpumap.h.
- Remove redundant err variable.
* tag 'perf-tools-for-v5.17-2022-01-22' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux:
perf tools: Remove redundant err variable
perf test: Add parse-events test for aliases with hyphens
perf test: Add pmu-events test for aliases with hyphens
perf parse-events: Support event alias in form foo-bar-baz
perf evsel: Override attr->sample_period for non-libpfm4 events
perf cpumap: Remove duplicate include in cpumap.h
perf cpumap: Migrate to libperf cpumap api
perf python: Fix cpu_map__item() building
perf script: Fix printing 'phys_addr' failure issue
tools headers UAPI: Sync files changed by new set_mempolicy_home_node syscall
tools headers UAPI: Sync x86 arch prctl headers with the kernel sources
perf machine: Use path__join() to compose a path instead of snprintf(dir, '/', filename)
perf evlist: No need to setup affinities when disabling events for pid targets
perf evlist: No need to setup affinities when enabling events for pid targets
perf stat: No need to setup affinities when starting a workload
perf affinity: Allow passing a NULL arg to affinity__cleanup()
perf probe: Fix ppc64 'perf probe add events failed' case
Linus Torvalds [Sun, 23 Jan 2022 06:07:02 +0000 (08:07 +0200)]
Merge tag 'trace-v5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull ftrace fix from Steven Rostedt:
"Fix s390 breakage from sorting mcount tables.
The latest merge of the tracing tree sorts the mcount table at build
time. But s390 appears to do things differently (like always) and
replaces the sorted table back to the original unsorted one. As the
ftrace algorithm depends on it being sorted, bad things happen when it
is not, and s390 experienced those bad things.
Add a new config to tell the boot if the mcount table is sorted or
not, and allow s390 to opt out of it"
* tag 'trace-v5.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
ftrace: Fix assuming build time sort works for s390
ftrace: Fix assuming build time sort works for s390
To speed up the boot process, as mcount_loc needs to be sorted for ftrace
to work properly, sorting it at build time is more efficient than boot up
and can save milliseconds of time. Unfortunately, this change broke s390
as it will modify the mcount_loc location after the sorting takes place
and will put back the unsorted locations. Since the sorting is skipped at
boot up if it is believed that it was sorted at run time, ftrace can crash
as its algorithms are dependent on the list being sorted.
Add a new config BUILDTIME_MCOUNT_SORT that is set when
BUILDTIME_TABLE_SORT but not if S390 is set. Use this config to determine
if sorting should take place at boot up.
Link: https://lore.kernel.org/all/yt9dee51ctfn.fsf@linux.ibm.com/ Fixes: ae67da61ee63 ("scripts: ftrace - move the sort-processing in ftrace_init") Reported-by: Sven Schnelle <svens@linux.ibm.com> Tested-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
projects / kernel.git / log