docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README

Commit fb12098d8ee4 ("docs: submit-checklist: Allow creating
cross-references for ABI README") assumes that t

docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README

Commit fb12098d8ee4 ("docs: submit-checklist: Allow creating
cross-references for ABI README") assumes that the path of
"Documentation/ABI/README" would be converted to a cross-ref to
the README.

However, as the README is included by the "kernel-abi" directive
at Documentation/admin-guide/abi.rst, the expected conversion
does not happen.

Instead, use the path where the "kernel-abi" directive exists for
the conversion to work. Restore the original path of README in
inline-literal form as an additional note for readers of the .rst
file.

Apply the same changes for translations.

Signed-off-by: Akira Yokosawa <[email protected]>
Fixes: fb12098d8ee4 ("docs: submit-checklist: Allow creating cross-references for ABI README")
Fixes: eb0c714120ba ("docs: translations: Allow creating cross-references for ABI README")
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Alex Shi <[email protected]>
Cc: Yanteng Si <[email protected]>
Cc: Dongliang Mu <[email protected]>
Cc: Hu Haowen <[email protected]>
Cc: Federico Vaga <[email protected]>
Cc: Carlos Bilbao <[email protected]>
Cc: Avadhut Naik <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

docs: submit-checklist: Allow creating cross-references for ABI README

Now that Documentation/ABI is processed by automarkup, let it
generate cross-references for the ABI README file.

Signed-off-by

docs: submit-checklist: Allow creating cross-references for ABI README

Now that Documentation/ABI is processed by automarkup, let it
generate cross-references for the ABI README file.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Link: https://lore.kernel.org/r/76e60ee8717551f3d15d7c92b9c93bbf2ca8cff3.1739254867.git.mchehab+huawei@kernel.org

show more ...

docs: submit-checklist: Expand on build tests against different word sizes

Existing sentence on cross-compilation that mentions ppc64 does not
make much sense in today's perspective.

Expand it for

docs: submit-checklist: Expand on build tests against different word sizes

Existing sentence on cross-compilation that mentions ppc64 does not
make much sense in today's perspective.

Expand it for the benefits of testing against architectures of
different word sizes and endianness.

Signed-off-by: Akira Yokosawa <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

docs: submit-checklist: use subheadings

During review (see Link), Jani Nikula suggested to use proper subheadings
instead of using italics to indicate the different new top-level
categories in the c

docs: submit-checklist: use subheadings

During review (see Link), Jani Nikula suggested to use proper subheadings
instead of using italics to indicate the different new top-level
categories in the checklist. Further the top heading should follow the
common scheme.

Use subheadings. Adjust to common heading adornment.

Link: https://lore.kernel.org/linux-doc/[email protected]/
Signed-off-by: Lukas Bulwahn <[email protected]>
Reviewed-by: Randy Dunlap <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Message-ID: <[email protected]>

show more ...

docs: submit-checklist: structure by category

While going through the submit checklist, the list order seemed rather
random, probably just by historical coincidences of always adding yet the
next po

docs: submit-checklist: structure by category

While going through the submit checklist, the list order seemed rather
random, probably just by historical coincidences of always adding yet the
next point someone thought of at the end of the list.

Structure and order them by the category of such activity,
reviewing, documenting, checking with tools, building and testing.

As the diff of the reordering is large:
Review code now includes previous points 1, 5 and 22.
Review Kconfig includes previous 6, 7 and 8.
Documenting includes previous 11, 15, 16, 17, 18 and 23.
Checking with tools includes previous 5, 9 and 10.
Building includes previous 2, 3, 20 and 24.
Testing includes previous 12, 13, 14, 19 and 21.

Previous point 4 (compile for ppc64) was merged into point 3 (build for
many architectures), as it was just a further note to cross-compiling.

Previous point 5 was split into one in review and one in checking
to have every previous point in the right category.
Point 11 was shortened, as building documentation is mentioned already
in Build your code, 1d.

A note that was presented visually much too aggressive in the HTML view was
turned into a simple "Note that..." sentence in the enumeration.

The recommendation to test with the -mm patchset (previous 21, now
testing, point 5) was updated to the current state of affairs to test with
a recent tag of linux-next.

Note that the previous first point still remains the first list even after
reordering. Randy confirmed that it was important to Stephen Rothwell to
keep 'include what you use' to be the first in the list.

While at it, replace the reference to the obsolete CONFIG_DEBUG_SLAB with
CONFIG_SLUB_DEBUG.

Reviewed-by: Randy Dunlap <[email protected]>
Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Lukas Bulwahn <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>
Message-ID: <[email protected]>

show more ...

doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line

You should use KCFLAGS to pass additional compiler flags from the
command line. Using EXTRA_CFLAGS is wrong.

EXTRA_CFLAGS is

doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line

You should use KCFLAGS to pass additional compiler flags from the
command line. Using EXTRA_CFLAGS is wrong.

EXTRA_CFLAGS is supposed to specify flags applied only to the current
Makefile (and now deprecated in favor of ccflags-y).

It is still used in arch/mips/kvm/Makefile (and possibly in external
modules too). Passing EXTRA_CFLAGS from the command line overwrites
it and breaks the build.

I also fixed drivers/gpu/drm/tilcdc/Makefile because commit 816175dd1fd7
("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in
EXTRA_CFLAGS") was based on the same misunderstanding.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Alex Shi <[email protected]>
Acked-by: Federico Vaga <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

docs: Remove make headers_check from checklist

Remove the make headers_check step from submit-checklist.rst as this is
no longer functional.

Signed-off-by: Milan Lakhani <[email protected]

docs: Remove make headers_check from checklist

Remove the make headers_check step from submit-checklist.rst as this is
no longer functional.

Signed-off-by: Milan Lakhani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

Documentation: process: Correct numbering

Renumber the steps in submit-checklist.rst as some numbers were skipped.

Signed-off-by: Milan Lakhani <[email protected]>
Link: https://lore.ke

Documentation: process: Correct numbering

Renumber the steps in submit-checklist.rst as some numbers were skipped.

Signed-off-by: Milan Lakhani <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

scripts: remove namespace.pl

namespace.pl is intended to help locate symbols which are defined but
are not used externally. The goal is to avoid bloat of the namespace in
the resulting kernel image.

scripts: remove namespace.pl

namespace.pl is intended to help locate symbols which are defined but
are not used externally. The goal is to avoid bloat of the namespace in
the resulting kernel image.

The script relies on object data, and only finds unused symbols for the
configuration used to generate that object data. This results in a lot
of false positive warnings such as symbols only used by a single
architecture, or symbols which are used externally only under certain
configurations.

Running namespace.pl using allyesconfig, allmodconfig, and
x86_64_defconfig yields the following results:

* allmodconfig
* 11122 unique symbol names with no external reference
* 1194 symbols listed as multiply defined
* 214 symbols it can't resolve
* allyesconfig
* 10997 unique symbol names with no external reference
* 1194 symbols listed as multiply defined
* 214 symbols it can't resolve
* x86_64_defconfig
* 5757 unique symbol names with no external reference
* 528 symbols listed as multiply defined
* 154 symbols it can't resolve

The script also has no way to easily limit the scope of the checks to
a given subset of the kernel, such as only checking for symbols defined
within a module or subsystem.

Discussion on public mailing lists seems to indicate that many view the
tool output as suspect or not very useful (see discussions at [1] and
[2] for further context).

As described by Masahiro Yamada at [2], namespace.pl provides 3 types of
checks: listing multiply defined symbols, resolving external symbols,
and warnings about symbols with no reference.

The first category of issues is easily caught by the linker as any set
of multiply defined symbols should fail to link. The second category of
issues is also caught by linking, as undefined symbols would cause
issues. Even with modules, these types of issues where a module relies
on an external symbol are caught by modpost.

The remaining category of issues reported is the list of symbols with no
external reference, and is the primary motivation of this script.
However, it ought to be clear from the above examples that the output is
difficult to sort through. Even allyesconfig has ~10000 entries.

The current submit-checklist indicates that patches ought to go through
namespacecheck and fix any new issues arising. But that itself presents
problems. As described at [1], many cases of reports are due to
configuration where a function is used externally by some configuration
settings. Prominent maintainers appear to dislike changes modify code
such that symbols become static based on CONFIG_* flags ([3], and [4])

One possible solution is to adjust the advice and indicate that we only
care about the output of namespacecheck on allyesconfig or allmodconfig
builds...

However, given the discussion at [2], I suspect that few people are
actively using this tool. It doesn't have a maintainer in the
MAINTAINERS flie, and it produces so many warnings for unused symbols
that it is difficult to use effectively. Thus, I propose we simply
remove it.

[1] https://lore.kernel.org/netdev/20200708164812.384ae8ea@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/
[2] https://lore.kernel.org/lkml/[email protected]/
[3] https://lore.kernel.org/netdev/[email protected]/
[4] https://lore.kernel.org/netdev/[email protected]/

Signed-off-by: Jacob Keller <[email protected]>
Acked-by: Randy Dunlap <[email protected]>
Acked-by: Jakub Kicinski <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

Documentation: submit-checklist: add clean builds for new Documentation

Add to Documentation/process/submit-checklist.rst that patch
submitters should run "make htmldocs" and verify that any
Documen

Documentation: submit-checklist: add clean builds for new Documentation

Add to Documentation/process/submit-checklist.rst that patch
submitters should run "make htmldocs" and verify that any
Documentation/ changes (patches) are clean (no new warnings/errors).

Signed-off-by: Randy Dunlap <[email protected]>
Reviewed-by: Mike Rapoport <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

docs: fix broken references to text files

Several references got broken due to txt to ReST conversion.

Several of them can be automatically fixed with:

scripts/documentation-file-ref-check --fix

docs: fix broken references to text files

Several references got broken due to txt to ReST conversion.

Several of them can be automatically fixed with:

scripts/documentation-file-ref-check --fix

Reviewed-by: Mathieu Poirier <[email protected]> # hwtracing/coresight/Kconfig
Reviewed-by: Paul E. McKenney <[email protected]> # memory-barrier.txt
Acked-by: Alex Shi <[email protected]> # translations/zh_CN
Acked-by: Federico Vaga <[email protected]> # translations/it_IT
Acked-by: Marc Zyngier <[email protected]> # kvm/arm64
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Link: https://lore.kernel.org/r/6f919ddb83a33b5f2a63b6b5f0575737bb2b36aa.1586881715.git.mchehab+huawei@kernel.org
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

docs: ioctl-number.txt: convert it to ReST format

The conversion itself is simple: add a markup for the
title of this file and add markups for both tables.

Yet, the big table here with IOCTL number

docs: ioctl-number.txt: convert it to ReST format

The conversion itself is simple: add a markup for the
title of this file and add markups for both tables.

Yet, the big table here with IOCTL numbers is badly formatted:
on several lines, the "Include File" column has some values that
are bigger than the reserved space there.

Also, on several places, a comment was misplaced at the "Include
File" space.

So, most of the work here is to actually ensure that each field
will be properly fixed.

Also worth to mention that some URLs have the asterisk character
on it. Well, Sphinx has an issue with asterisks in the middle
of an string. As this is URL, use the alternate format: %2A.

As a side effect of this patch, it is now a lot easier to see that
some reserved ioctl numbers are missing the include files
where it is supposed to be used.

PS.: While this is part of a subdir, I opted to convert this
single file alone, as this file has a potential of conflicts,
as most subsystem maintainers touch it.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>

show more ...

docs: kbuild: convert docs to ReST and rename to *.rst

The kbuild documentation clearly shows that the documents
there are written at different times: some use markdown,
some use their own peculiar

docs: kbuild: convert docs to ReST and rename to *.rst

The kbuild documentation clearly shows that the documents
there are written at different times: some use markdown,
some use their own peculiar logic to split sections.

Convert everything to ReST without affecting too much
the author's style and avoiding adding uneeded markups.

The conversion is actually:
- add blank lines and identation in order to identify paragraphs;
- fix tables markups;
- add some lists markups;
- mark literal blocks;
- adjust title markups.

At its new index.rst, let's add a :orphan: while this is not linked to
the main index.rst file, in order to avoid build warnings.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

block: remove CONFIG_LBDAF

Currently support for 64-bit sector_t and blkcnt_t is optional on 32-bit
architectures. These types are required to support block device and/or
file sizes larger than 2 T

block: remove CONFIG_LBDAF

Currently support for 64-bit sector_t and blkcnt_t is optional on 32-bit
architectures. These types are required to support block device and/or
file sizes larger than 2 TiB, and have generally defaulted to on for
a long time. Enabling the option only increases the i386 tinyconfig
size by 145 bytes, and many data structures already always use
64-bit values for their in-core and on-disk data structures anyway,
so there should not be a large change in dynamic memory usage either.

Dropping this option removes a somewhat weird non-default config that
has cause various bugs or compiler warnings when actually used.

Signed-off-by: Christoph Hellwig <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>

show more ...

docs: fix process/submit-checklist.rst Sphinx warning

add missing indent whitespace to list item, fixes the warning:

- process/submit-checklist.rst:41: WARNING: Enumerated list ends without a blank

docs: fix process/submit-checklist.rst Sphinx warning

add missing indent whitespace to list item, fixes the warning:

- process/submit-checklist.rst:41: WARNING: Enumerated list ends without a blank
line; unexpected unindent.

Signed-off-by: Markus Heiser <[email protected]>
Reviewed-by: Darren Hart (VMware) <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

Documentation/process: Add CONFIG default value to submit-checklist

Add default value review to the submit checklist, referring to the
preference for "default n" from the previous patch added to
Doc

Documentation/process: Add CONFIG default value to submit-checklist

Add default value review to the submit checklist, referring to the
preference for "default n" from the previous patch added to
Documentation/kbuild/kconfig-language.txt.

Cc: "Yann E. MORIN" <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Michal Marek <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Darren Hart (VMware) <[email protected]>
Signed-off-by: Jonathan Corbet <[email protected]>

show more ...

docs: fix locations of several documents that got moved

The previous patch renamed several files that are cross-referenced
along the Kernel documentation. Adjust the links to point to
the right plac

docs: fix locations of several documents that got moved

The previous patch renamed several files that are cross-referenced
along the Kernel documentation. Adjust the links to point to
the right places.

Signed-off-by: Mauro Carvalho Chehab <[email protected]>

show more ...

docs-rst: add documents to development-process

Add several documents to the development-process ReST book.

As we don't want renames, use symlinks instead, keeping those
documents on their original

docs-rst: add documents to development-process

Add several documents to the development-process ReST book.

As we don't want renames, use symlinks instead, keeping those
documents on their original place.

Acked-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>

show more ...