A few late-arriving documentation fixes, including some oprofile cleanup, a
kernel-doc fix, some regression-reporting updates, and the usual minor fixes. -----BEGIN PGP SIGNATURE----- iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAmCTCMoPHGNvcmJldEBs d24ubmV0AAoJEBdDWhNsDH5YsecH/jSLfUKS8BrIR8CcwG7bEl3PLQnCRe2Qc/+P aTkJf2v9WRMdNgjf6tIoYL0EqRtyDT7bL5NgsfxqX9gqTxjRdiRoT1ZvKmNFD9Zk 4vPewVEDxQkz1Odq+vh0wLWMWV+AktHWFPRZlpfqTZ7mt9l8pk55LWJNKQs5dOVZ d6w3XoE31WbQHi6CBFwTFoHeFAXnvYg+LUkeuYpaFpYIB0zvTvTThMffSWlPzsUk ADRJgUQ0TIXhPJ52Ak0y+sy24AYu/0RjUTaduoUz4eEp+toGqp21ZCXuRfPXobOG Ai42D3FgHZGaG/hIkHmpny5rRaxF6kK+pGkFQq04HW/j2BwMZac= =he/3 -----END PGP SIGNATURE----- Merge tag 'docs-5.13-2' of git://git.lwn.net/linux Pull documentation fixes from Jonathan Corbet: "A few late-arriving documentation fixes, including some oprofile cleanup, a kernel-doc fix, some regression-reporting updates, and the usual minor fixes" * tag 'docs-5.13-2' of git://git.lwn.net/linux: Enlisted oprofile version line removed oprofiled version output line removed from the list Removed the oprofiled version option docs: reporting-issues.rst: CC subsystem and maintainers on regressions docs: correct URL to bios and kernel developer's guide docs/core-api: Consistent code style docs/zh_CN: Adjust order and content of zh_CN/index.rst Documentation: input: joydev file corrections docs: Fix typo in Documentation/x86/x86_64/5level-paging.rst kernel-doc: Add support for __deprecated
This commit is contained in:
Linus Torvalds
commit
a3f53e8adf
|
|
@ -285,7 +285,7 @@ Description: Disable L3 cache indices
|
|||
|
||||
All AMD processors with L3 caches provide this functionality.
|
||||
For details, see BKDGs at
|
||||
http://developer.amd.com/documentation/guides/Pages/default.aspx
|
||||
https://www.amd.com/en/support/tech-docs?keyword=bios+kernel
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/cpufreq/boost
|
||||
|
|
|
|||
|
|
@ -24,7 +24,8 @@ longterm series? One still supported? Then search the `LKML
|
|||
you don't find any, install `the latest release from that series
|
||||
<https://kernel.org/>`_. If it still shows the issue, report it to the stable
|
||||
mailing list (stable@vger.kernel.org) and CC the regressions list
|
||||
(regressions@lists.linux.dev).
|
||||
(regressions@lists.linux.dev); ideally also CC the maintainer and the mailing
|
||||
list for the subsystem in question.
|
||||
|
||||
In all other cases try your best guess which kernel part might be causing the
|
||||
issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
|
||||
|
|
@ -48,8 +49,9 @@ before the issue occurs.
|
|||
If you are facing multiple issues with the Linux kernel at once, report each
|
||||
separately. While writing your report, include all information relevant to the
|
||||
issue, like the kernel and the distro used. In case of a regression, CC the
|
||||
regressions mailing list (regressions@lists.linux.dev) to your report; also try
|
||||
to include the commit-id of the change causing it, which a bisection can find.
|
||||
regressions mailing list (regressions@lists.linux.dev) to your report. Also try
|
||||
to pin-point the culprit with a bisection; if you succeed, include its
|
||||
commit-id and CC everyone in the sign-off-by chain.
|
||||
|
||||
Once the report is out, answer any questions that come up and help where you
|
||||
can. That includes keeping the ball rolling by occasionally retesting with newer
|
||||
|
|
@ -198,10 +200,11 @@ report them:
|
|||
|
||||
* Send a short problem report to the Linux stable mailing list
|
||||
(stable@vger.kernel.org) and CC the Linux regressions mailing list
|
||||
(regressions@lists.linux.dev). Roughly describe the issue and ideally
|
||||
explain how to reproduce it. Mention the first version that shows the
|
||||
problem and the last version that's working fine. Then wait for further
|
||||
instructions.
|
||||
(regressions@lists.linux.dev); if you suspect the cause in a particular
|
||||
subsystem, CC its maintainer and its mailing list. Roughly describe the
|
||||
issue and ideally explain how to reproduce it. Mention the first version
|
||||
that shows the problem and the last version that's working fine. Then
|
||||
wait for further instructions.
|
||||
|
||||
The reference section below explains each of these steps in more detail.
|
||||
|
||||
|
|
@ -768,7 +771,9 @@ regular internet search engine and add something like
|
|||
the results to the archives at that URL.
|
||||
|
||||
It's also wise to check the internet, LKML and maybe bugzilla.kernel.org again
|
||||
at this point.
|
||||
at this point. If your report needs to be filed in a bug tracker, you may want
|
||||
to check the mailing list archives for the subsystem as well, as someone might
|
||||
have reported it only there.
|
||||
|
||||
For details how to search and what to do if you find matching reports see
|
||||
"Search for existing reports, first run" above.
|
||||
|
|
@ -1249,9 +1254,10 @@ and the oldest where the issue occurs (say 5.8-rc1).
|
|||
|
||||
When sending the report by mail, CC the Linux regressions mailing list
|
||||
(regressions@lists.linux.dev). In case the report needs to be filed to some web
|
||||
tracker, proceed to do so; once filed, forward the report by mail to the
|
||||
regressions list. Make sure to inline the forwarded report, hence do not attach
|
||||
it. Also add a short note at the top where you mention the URL to the ticket.
|
||||
tracker, proceed to do so. Once filed, forward the report by mail to the
|
||||
regressions list; CC the maintainer and the mailing list for the subsystem in
|
||||
question. Make sure to inline the forwarded report, hence do not attach it.
|
||||
Also add a short note at the top where you mention the URL to the ticket.
|
||||
|
||||
When mailing or forwarding the report, in case of a successful bisection add the
|
||||
author of the culprit to the recipients; also CC everyone in the signed-off-by
|
||||
|
|
@ -1536,17 +1542,20 @@ Report the regression
|
|||
|
||||
*Send a short problem report to the Linux stable mailing list
|
||||
(stable@vger.kernel.org) and CC the Linux regressions mailing list
|
||||
(regressions@lists.linux.dev). Roughly describe the issue and ideally
|
||||
explain how to reproduce it. Mention the first version that shows the
|
||||
problem and the last version that's working fine. Then wait for further
|
||||
instructions.*
|
||||
(regressions@lists.linux.dev); if you suspect the cause in a particular
|
||||
subsystem, CC its maintainer and its mailing list. Roughly describe the
|
||||
issue and ideally explain how to reproduce it. Mention the first version
|
||||
that shows the problem and the last version that's working fine. Then
|
||||
wait for further instructions.*
|
||||
|
||||
When reporting a regression that happens within a stable or longterm kernel
|
||||
line (say when updating from 5.10.4 to 5.10.5) a brief report is enough for
|
||||
the start to get the issue reported quickly. Hence a rough description is all
|
||||
it takes.
|
||||
the start to get the issue reported quickly. Hence a rough description to the
|
||||
stable and regressions mailing list is all it takes; but in case you suspect
|
||||
the cause in a particular subsystem, CC its maintainers and its mailing list
|
||||
as well, because that will speed things up.
|
||||
|
||||
But note, it helps developers a great deal if you can specify the exact version
|
||||
And note, it helps developers a great deal if you can specify the exact version
|
||||
that introduced the problem. Hence if possible within a reasonable time frame,
|
||||
try to find that version using vanilla kernels. Lets assume something broke when
|
||||
your distributor released a update from Linux kernel 5.10.5 to 5.10.8. Then as
|
||||
|
|
@ -1563,7 +1572,9 @@ pinpoint the exact change that causes the issue (which then can easily get
|
|||
reverted to fix the issue quickly). Hence consider to do a proper bisection
|
||||
right away if time permits. See the section 'Special care for regressions' and
|
||||
the document 'Documentation/admin-guide/bug-bisect.rst' for details how to
|
||||
perform one.
|
||||
perform one. In case of a successful bisection add the author of the culprit to
|
||||
the recipients; also CC everyone in the signed-off-by chain, which you find at
|
||||
the end of its commit message.
|
||||
|
||||
|
||||
Reference for "Reporting issues only occurring in older kernel version lines"
|
||||
|
|
|
|||
|
|
@ -43,14 +43,14 @@ exporting of kernel symbols to the kernel symbol table, variants of these are
|
|||
available to export symbols into a certain namespace: EXPORT_SYMBOL_NS() and
|
||||
EXPORT_SYMBOL_NS_GPL(). They take one additional argument: the namespace.
|
||||
Please note that due to macro expansion that argument needs to be a
|
||||
preprocessor symbol. E.g. to export the symbol `usb_stor_suspend` into the
|
||||
namespace `USB_STORAGE`, use::
|
||||
preprocessor symbol. E.g. to export the symbol ``usb_stor_suspend`` into the
|
||||
namespace ``USB_STORAGE``, use::
|
||||
|
||||
EXPORT_SYMBOL_NS(usb_stor_suspend, USB_STORAGE);
|
||||
|
||||
The corresponding ksymtab entry struct `kernel_symbol` will have the member
|
||||
`namespace` set accordingly. A symbol that is exported without a namespace will
|
||||
refer to `NULL`. There is no default namespace if none is defined. `modpost`
|
||||
The corresponding ksymtab entry struct ``kernel_symbol`` will have the member
|
||||
``namespace`` set accordingly. A symbol that is exported without a namespace will
|
||||
refer to ``NULL``. There is no default namespace if none is defined. ``modpost``
|
||||
and kernel/module.c make use the namespace at build time or module load time,
|
||||
respectively.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ and EXPORT_SYMBOL_GPL() macro expansions that do not specify a namespace.
|
|||
|
||||
There are multiple ways of specifying this define and it depends on the
|
||||
subsystem and the maintainer's preference, which one to use. The first option
|
||||
is to define the default namespace in the `Makefile` of the subsystem. E.g. to
|
||||
is to define the default namespace in the ``Makefile`` of the subsystem. E.g. to
|
||||
export all symbols defined in usb-common into the namespace USB_COMMON, add a
|
||||
line like this to drivers/usb/common/Makefile::
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ using a statement like::
|
|||
|
||||
MODULE_IMPORT_NS(USB_STORAGE);
|
||||
|
||||
This will create a `modinfo` tag in the module for each imported namespace.
|
||||
This will create a ``modinfo`` tag in the module for each imported namespace.
|
||||
This has the side effect, that the imported namespaces of a module can be
|
||||
inspected with modinfo::
|
||||
|
||||
|
|
@ -113,7 +113,7 @@ metadata definitions like MODULE_AUTHOR() or MODULE_LICENSE(). Refer to section
|
|||
4. Loading Modules that use namespaced Symbols
|
||||
==============================================
|
||||
|
||||
At module loading time (e.g. `insmod`), the kernel will check each symbol
|
||||
At module loading time (e.g. ``insmod``), the kernel will check each symbol
|
||||
referenced from the module for its availability and whether the namespace it
|
||||
might be exported to has been imported by the module. The default behaviour of
|
||||
the kernel is to reject loading modules that don't specify sufficient imports.
|
||||
|
|
@ -138,19 +138,19 @@ missing imports. Fixing missing imports can be done with::
|
|||
A typical scenario for module authors would be::
|
||||
|
||||
- write code that depends on a symbol from a not imported namespace
|
||||
- `make`
|
||||
- ``make``
|
||||
- notice the warning of modpost telling about a missing import
|
||||
- run `make nsdeps` to add the import to the correct code location
|
||||
- run ``make nsdeps`` to add the import to the correct code location
|
||||
|
||||
For subsystem maintainers introducing a namespace, the steps are very similar.
|
||||
Again, `make nsdeps` will eventually add the missing namespace imports for
|
||||
Again, ``make nsdeps`` will eventually add the missing namespace imports for
|
||||
in-tree modules::
|
||||
|
||||
- move or add symbols to a namespace (e.g. with EXPORT_SYMBOL_NS())
|
||||
- `make` (preferably with an allmodconfig to cover all in-kernel
|
||||
- ``make`` (preferably with an allmodconfig to cover all in-kernel
|
||||
modules)
|
||||
- notice the warning of modpost telling about a missing import
|
||||
- run `make nsdeps` to add the import to the correct code location
|
||||
- run ``make nsdeps`` to add the import to the correct code location
|
||||
|
||||
You can also run nsdeps for external module builds. A typical usage is::
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,7 @@ The possible values of ``type`` are::
|
|||
#define JS_EVENT_INIT 0x80 /* initial state of device */
|
||||
|
||||
As mentioned above, the driver will issue synthetic JS_EVENT_INIT ORed
|
||||
events on open. That is, if it's issuing a INIT BUTTON event, the
|
||||
events on open. That is, if it's issuing an INIT BUTTON event, the
|
||||
current type value will be::
|
||||
|
||||
int type = JS_EVENT_BUTTON | JS_EVENT_INIT; /* 0x81 */
|
||||
|
|
@ -100,8 +100,8 @@ is, you have both an axis 0 and a button 0). Generally,
|
|||
=============== =======
|
||||
|
||||
Hats vary from one joystick type to another. Some can be moved in 8
|
||||
directions, some only in 4, The driver, however, always reports a hat as two
|
||||
independent axis, even if the hardware doesn't allow independent movement.
|
||||
directions, some only in 4. The driver, however, always reports a hat as two
|
||||
independent axes, even if the hardware doesn't allow independent movement.
|
||||
|
||||
|
||||
js_event.value
|
||||
|
|
@ -188,10 +188,10 @@ One reason for emptying the queue is that if it gets full you'll start
|
|||
missing events since the queue is finite, and older events will get
|
||||
overwritten.
|
||||
|
||||
The other reason is that you want to know all what happened, and not
|
||||
The other reason is that you want to know all that happened, and not
|
||||
delay the processing till later.
|
||||
|
||||
Why can get the queue full? Because you don't empty the queue as
|
||||
Why can the queue get full? Because you don't empty the queue as
|
||||
mentioned, or because too much time elapses from one read to another
|
||||
and too many events to store in the queue get generated. Note that
|
||||
high system load may contribute to space those reads even more.
|
||||
|
|
@ -277,7 +277,7 @@ to be in the stable part of the API, and therefore may change without
|
|||
warning in following releases of the driver.
|
||||
|
||||
Both JSIOCSCORR and JSIOCGCORR expect &js_corr to be able to hold
|
||||
information for all axis. That is, struct js_corr corr[MAX_AXIS];
|
||||
information for all axes. That is, struct js_corr corr[MAX_AXIS];
|
||||
|
||||
struct js_corr is defined as::
|
||||
|
||||
|
|
@ -328,7 +328,7 @@ To test the state of the buttons,
|
|||
second_button_state = js.buttons & 2;
|
||||
|
||||
The axis values do not have a defined range in the original 0.x driver,
|
||||
except for that the values are non-negative. The 1.2.8+ drivers use a
|
||||
except that the values are non-negative. The 1.2.8+ drivers use a
|
||||
fixed range for reporting the values, 1 being the minimum, 128 the
|
||||
center, and 255 maximum value.
|
||||
|
||||
|
|
|
|||
|
|
@ -133,15 +133,15 @@ And add a line to your rc script executing that file::
|
|||
This way, after the next reboot your joystick will remain calibrated. You
|
||||
can also add the ``jscal -p`` line to your shutdown script.
|
||||
|
||||
HW specific driver information
|
||||
==============================
|
||||
Hardware-specific driver information
|
||||
====================================
|
||||
|
||||
In this section each of the separate hardware specific drivers is described.
|
||||
|
||||
Analog joysticks
|
||||
----------------
|
||||
|
||||
The analog.c uses the standard analog inputs of the gameport, and thus
|
||||
The analog.c driver uses the standard analog inputs of the gameport, and thus
|
||||
supports all standard joysticks and gamepads. It uses a very advanced
|
||||
routine for this, allowing for data precision that can't be found on any
|
||||
other system.
|
||||
|
|
@ -266,7 +266,7 @@ to:
|
|||
* Logitech WingMan Extreme Digital 3D
|
||||
|
||||
ADI devices are autodetected, and the driver supports up to two (any
|
||||
combination of) devices on a single gameport, using an Y-cable or chained
|
||||
combination of) devices on a single gameport, using a Y-cable or chained
|
||||
together.
|
||||
|
||||
Logitech WingMan Joystick, Logitech WingMan Attack, Logitech WingMan
|
||||
|
|
@ -288,7 +288,7 @@ supports:
|
|||
* Gravis Xterminator DualControl
|
||||
|
||||
All these devices are autodetected, and you can even use any combination
|
||||
of up to two of these pads either chained together or using an Y-cable on a
|
||||
of up to two of these pads either chained together or using a Y-cable on a
|
||||
single gameport.
|
||||
|
||||
GrIP MultiPort isn't supported yet. Gravis Stinger is a serial device and is
|
||||
|
|
@ -311,7 +311,7 @@ allow connecting analog joysticks to them, you'll need to load the analog
|
|||
driver as well to handle the attached joysticks.
|
||||
|
||||
The trackball should work with USB mousedev module as a normal mouse. See
|
||||
the USB documentation for how to setup an USB mouse.
|
||||
the USB documentation for how to setup a USB mouse.
|
||||
|
||||
ThrustMaster DirectConnect (BSP)
|
||||
--------------------------------
|
||||
|
|
@ -332,7 +332,7 @@ If you have one of these, contact me.
|
|||
|
||||
TMDC devices are autodetected, and thus no parameters to the module
|
||||
are needed. Up to two TMDC devices can be connected to one gameport, using
|
||||
an Y-cable.
|
||||
a Y-cable.
|
||||
|
||||
Creative Labs Blaster
|
||||
---------------------
|
||||
|
|
@ -342,7 +342,7 @@ the:
|
|||
|
||||
* Creative Blaster GamePad Cobra
|
||||
|
||||
Up to two of these can be used on a single gameport, using an Y-cable.
|
||||
Up to two of these can be used on a single gameport, using a Y-cable.
|
||||
|
||||
Genius Digital joysticks
|
||||
------------------------
|
||||
|
|
@ -381,7 +381,7 @@ card, 16 in case you have two in your system.
|
|||
Trident 4DWave / Aureal Vortex
|
||||
------------------------------
|
||||
|
||||
Soundcards with a Trident 4DWave DX/NX or Aureal Vortex/Vortex2 chipsets
|
||||
Soundcards with a Trident 4DWave DX/NX or Aureal Vortex/Vortex2 chipset
|
||||
provide an "Enhanced Game Port" mode where the soundcard handles polling the
|
||||
joystick. This mode is supported by the pcigame.c module. Once loaded the
|
||||
analog driver can use the enhanced features of these gameports..
|
||||
|
|
@ -454,7 +454,7 @@ Devices currently supported by spaceball.c are:
|
|||
* SpaceTec SpaceBall 4000 FLX
|
||||
|
||||
In addition to having the spaceorb/spaceball and serport modules in the
|
||||
kernel, you also need to attach a serial port to it. to do that, run the
|
||||
kernel, you also need to attach a serial port to it. To do that, run the
|
||||
inputattach program::
|
||||
|
||||
inputattach --spaceorb /dev/tts/x &
|
||||
|
|
@ -466,7 +466,7 @@ or::
|
|||
where /dev/tts/x is the serial port which the device is connected to. After
|
||||
doing this, the device will be reported and will start working.
|
||||
|
||||
There is one caveat with the SpaceOrb. The button #6, the on the bottom
|
||||
There is one caveat with the SpaceOrb. The button #6, the one on the bottom
|
||||
side of the orb, although reported as an ordinary button, causes internal
|
||||
recentering of the spaceorb, moving the zero point to the position in which
|
||||
the ball is at the moment of pressing the button. So, think first before
|
||||
|
|
@ -500,7 +500,7 @@ joy-magellan module. It currently supports only the:
|
|||
* Magellan 3D
|
||||
* Space Mouse
|
||||
|
||||
models, the additional buttons on the 'Plus' versions are not supported yet.
|
||||
models; the additional buttons on the 'Plus' versions are not supported yet.
|
||||
|
||||
To use it, you need to attach the serial port to the driver using the::
|
||||
|
||||
|
|
@ -575,7 +575,7 @@ FAQ
|
|||
:A: The device files don't exist. Create them (see section 2.2).
|
||||
|
||||
:Q: Is it possible to connect my old Atari/Commodore/Amiga/console joystick
|
||||
or pad that uses a 9-pin D-type cannon connector to the serial port of my
|
||||
or pad that uses a 9-pin D-type Cannon connector to the serial port of my
|
||||
PC?
|
||||
:A: Yes, it is possible, but it'll burn your serial port or the pad. It
|
||||
won't work, of course.
|
||||
|
|
|
|||
|
|
@ -48,7 +48,6 @@ quota-tools 3.09 quota -V
|
|||
PPP 2.4.0 pppd --version
|
||||
nfs-utils 1.0.5 showmount --version
|
||||
procps 3.2.0 ps --version
|
||||
oprofile 0.9 oprofiled --version
|
||||
udev 081 udevd --version
|
||||
grub 0.93 grub --version || grub-install --version
|
||||
mcelog 0.6 mcelog --version
|
||||
|
|
|
|||
|
|
@ -51,7 +51,6 @@ quota-tools 3.09 quota -V
|
|||
PPP 2.4.0 pppd --version
|
||||
nfs-utils 1.0.5 showmount --version
|
||||
procps 3.2.0 ps --version
|
||||
oprofile 0.9 oprofiled --version
|
||||
udev 081 udevd --version
|
||||
grub 0.93 grub --version || grub-install --version
|
||||
mcelog 0.6 mcelog --version
|
||||
|
|
|
|||
|
|
@ -1,36 +1,184 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. raw:: latex
|
||||
|
||||
\renewcommand\thesection*
|
||||
\renewcommand\thesubsection*
|
||||
|
||||
.. _linux_doc_zh:
|
||||
|
||||
中文翻译
|
||||
========
|
||||
|
||||
这些手册包含有关如何开发内核的整体信息。内核社区非常庞大，一年下来有数千名开发
|
||||
人员做出贡献。 与任何大型社区一样，知道如何完成任务将使得更改合并的过程变得更
|
||||
加容易。
|
||||
|
||||
翻译计划:
|
||||
内核中文文档欢迎任何翻译投稿，特别是关于内核用户和管理员指南部分。
|
||||
.. note::
|
||||
|
||||
**翻译计划:**
|
||||
内核中文文档欢迎任何翻译投稿，特别是关于内核用户和管理员指南部分。
|
||||
|
||||
许可证文档
|
||||
----------
|
||||
|
||||
下面的文档介绍了Linux内核源代码的许可证（GPLv2）、如何在源代码树中正确标记
|
||||
单个文件的许可证、以及指向完整许可证文本的链接。
|
||||
|
||||
* Documentation/translations/zh_CN/process/license-rules.rst
|
||||
|
||||
用户文档
|
||||
--------
|
||||
|
||||
下面的手册是为内核用户编写的——即那些试图让它在给定系统上以最佳方式工作的
|
||||
用户。
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
admin-guide/index
|
||||
|
||||
TODOList:
|
||||
|
||||
* kbuild/index
|
||||
|
||||
固件相关文档
|
||||
------------
|
||||
|
||||
下列文档描述了内核需要的平台固件相关信息。
|
||||
|
||||
TODOList:
|
||||
|
||||
* firmware-guide/index
|
||||
* devicetree/index
|
||||
|
||||
应用程序开发人员文档
|
||||
--------------------
|
||||
|
||||
用户空间API手册涵盖了描述应用程序开发人员可见内核接口方面的文档。
|
||||
|
||||
TODOlist:
|
||||
|
||||
* userspace-api/index
|
||||
|
||||
内核开发简介
|
||||
------------
|
||||
|
||||
这些手册包含有关如何开发内核的整体信息。内核社区非常庞大，一年下来有数千名
|
||||
开发人员做出贡献。与任何大型社区一样，知道如何完成任务将使得更改合并的过程
|
||||
变得更加容易。
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
process/index
|
||||
dev-tools/index
|
||||
doc-guide/index
|
||||
kernel-hacking/index
|
||||
filesystems/index
|
||||
arm64/index
|
||||
sound/index
|
||||
cpu-freq/index
|
||||
mips/index
|
||||
iio/index
|
||||
riscv/index
|
||||
|
||||
TODOList:
|
||||
|
||||
* trace/index
|
||||
* maintainer/index
|
||||
* fault-injection/index
|
||||
* livepatch/index
|
||||
* rust/index
|
||||
|
||||
内核API文档
|
||||
-----------
|
||||
|
||||
以下手册从内核开发人员的角度详细介绍了特定的内核子系统是如何工作的。这里的
|
||||
大部分信息都是直接从内核源代码获取的，并根据需要添加补充材料（或者至少是在
|
||||
我们设法添加的时候——可能不是所有的都是有需要的）。
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
core-api/index
|
||||
cpu-freq/index
|
||||
iio/index
|
||||
sound/index
|
||||
filesystems/index
|
||||
|
||||
TODOList:
|
||||
|
||||
* driver-api/index
|
||||
* locking/index
|
||||
* accounting/index
|
||||
* block/index
|
||||
* cdrom/index
|
||||
* ide/index
|
||||
* fb/index
|
||||
* fpga/index
|
||||
* hid/index
|
||||
* i2c/index
|
||||
* isdn/index
|
||||
* infiniband/index
|
||||
* leds/index
|
||||
* netlabel/index
|
||||
* networking/index
|
||||
* pcmcia/index
|
||||
* power/index
|
||||
* target/index
|
||||
* timers/index
|
||||
* spi/index
|
||||
* w1/index
|
||||
* watchdog/index
|
||||
* virt/index
|
||||
* input/index
|
||||
* hwmon/index
|
||||
* gpu/index
|
||||
* security/index
|
||||
* crypto/index
|
||||
* vm/index
|
||||
* bpf/index
|
||||
* usb/index
|
||||
* PCI/index
|
||||
* scsi/index
|
||||
* misc-devices/index
|
||||
* scheduler/index
|
||||
* mhi/index
|
||||
|
||||
体系结构无关文档
|
||||
----------------
|
||||
|
||||
TODOList:
|
||||
|
||||
* asm-annotations
|
||||
|
||||
特定体系结构文档
|
||||
----------------
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
mips/index
|
||||
arm64/index
|
||||
riscv/index
|
||||
openrisc/index
|
||||
|
||||
TODOList:
|
||||
|
||||
* arm/index
|
||||
* ia64/index
|
||||
* m68k/index
|
||||
* nios2/index
|
||||
* parisc/index
|
||||
* powerpc/index
|
||||
* s390/index
|
||||
* sh/index
|
||||
* sparc/index
|
||||
* x86/index
|
||||
* xtensa/index
|
||||
|
||||
其他文档
|
||||
--------
|
||||
|
||||
有几份未排序的文档似乎不适合放在文档的其他部分，或者可能需要进行一些调整和/或
|
||||
转换为reStructureText格式，也有可能太旧。
|
||||
|
||||
TODOList:
|
||||
|
||||
* staging/index
|
||||
* watch_queue
|
||||
|
||||
目录和表格
|
||||
----------
|
||||
|
||||
|
|
|
|||
|
|
@ -6,9 +6,9 @@
|
|||
|
||||
Overview
|
||||
========
|
||||
Original x86-64 was limited by 4-level paing to 256 TiB of virtual address
|
||||
Original x86-64 was limited by 4-level paging to 256 TiB of virtual address
|
||||
space and 64 TiB of physical address space. We are already bumping into
|
||||
this limit: some vendors offers servers with 64 TiB of memory today.
|
||||
this limit: some vendors offer servers with 64 TiB of memory today.
|
||||
|
||||
To overcome the limitation upcoming hardware will introduce support for
|
||||
5-level paging. It is a straight-forward extension of the current page
|
||||
|
|
|
|||
|
|
@ -1777,6 +1777,7 @@ sub dump_function($$) {
|
|||
$prototype =~ s/^noinline +//;
|
||||
$prototype =~ s/__init +//;
|
||||
$prototype =~ s/__init_or_module +//;
|
||||
$prototype =~ s/__deprecated +//;
|
||||
$prototype =~ s/__flatten +//;
|
||||
$prototype =~ s/__meminit +//;
|
||||
$prototype =~ s/__must_check +//;
|
||||
|
|
|
|||
|
|
@ -47,7 +47,6 @@ BEGIN {
|
|||
printversion("Net-tools", version("ifconfig --version"))
|
||||
printversion("Kbd", version("loadkeys -V"))
|
||||
printversion("Console-tools", version("loadkeys -V"))
|
||||
printversion("Oprofile", version("oprofiled --version"))
|
||||
printversion("Sh-utils", version("expr --v"))
|
||||
printversion("Udev", version("udevadm --version"))
|
||||
printversion("Wireless-tools", version("iwconfig --version"))
|
||||
|
|
|
|||
Loading…
Reference in New Issue