Another not-too-busy cycle for documentation, including:
- Some build-system changes to detect the variable fonts installed by some
distributions that can break the PDF build.
- Various updates and additions to the Spanish, Chinese, Italian, and
Japanese translations.
- Update the stable-kernel rules to match modern practice
...and the usual array of corrections, updates, and typo fixes.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAmY9ASYACgkQF0NaE2wM
flhPAwf/SYwHTBhKo0Xy3WsY3PHm4hsYVDwQ/Nfr6oa1mF+x4npxcN1RzPJd8iB9
zXlynnBkptwvEoukJV2hw+gVwO9ixyqJzIt7AmRFgA5cywhklpxQQAVelQG4ISR2
8M7LOXIjROJdY3OymPcQ2YF1m000tB9Khx7uvWrvMZEasXND/ITi9mFIJiOk841C
5wGTHmYKjJwuqTm6CsghAgLJkRYGHD+gtp4w8wQwQzIHJ6B8SnbVPSnYYqJ8Qt/V
31AEBgV3WJhmNiyNgP/p3rtDTCXBowSK8klOMa5CW3FQEIb4SQL/uBZ8qR8FQo2c
l1zsuPKKJOqe9T+POWHXdjoryZn1Ug==
=8fUD
-----END PGP SIGNATURE-----
Merge tag 'docs-6.10' of git://git.lwn.net/linux
Pull documentation updates from Jonathan Corbet:
"Another not-too-busy cycle for documentation, including:
- Some build-system changes to detect the variable fonts installed by
some distributions that can break the PDF build.
- Various updates and additions to the Spanish, Chinese, Italian, and
Japanese translations.
- Update the stable-kernel rules to match modern practice
... and the usual array of corrections, updates, and typo fixes"
* tag 'docs-6.10' of git://git.lwn.net/linux: (42 commits)
cgroup: Add documentation for missing zswap memory.stat
kernel-doc: Added "*" in $type_constants2 to fix 'make htmldocs' warning.
docs:core-api: fixed typos and grammar in printk-index page
Documentation: tracing: Fix spelling mistakes
docs/zh_CN/rust: Update the translation of quick-start to 6.9-rc4
docs/zh_CN/rust: Update the translation of general-information to 6.9-rc4
docs/zh_CN/rust: Update the translation of coding-guidelines to 6.9-rc4
docs/zh_CN/rust: Update the translation of arch-support to 6.9-rc4
docs: stable-kernel-rules: fix typo sent->send
docs/zh_CN: remove two inconsistent spaces
docs: scripts/check-variable-fonts.sh: Improve commands for detection
docs: stable-kernel-rules: create special tag to flag 'no backporting'
docs: stable-kernel-rules: explain use of stable@kernel.org (w/o @vger.)
docs: stable-kernel-rules: remove code-labels tags and a indention level
docs: stable-kernel-rules: call mainline by its name and change example
docs: stable-kernel-rules: reduce redundancy
docs, kprobes: Add riscv as supported architecture
Docs: typos/spelling
docs: kernel_include.py: Cope with docutils 0.21
docs: ja_JP/howto: Catch up update in v6.8
...
This commit is contained in:
Linus Torvalds
commit
8815da98e0
1
.mailmap
1
.mailmap
|
|
@ -133,6 +133,7 @@ Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
|
|||
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
|
||||
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
|
||||
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
|
||||
Carlos Bilbao <carlos.bilbao.osdev@gmail.com> <carlos.bilbao@amd.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
|
|
|
|||
|
|
@ -28,6 +28,10 @@ BUILDDIR = $(obj)/output
|
|||
PDFLATEX = xelatex
|
||||
LATEXOPTS = -interaction=batchmode -no-shell-escape
|
||||
|
||||
# For denylisting "variable font" files
|
||||
# Can be overridden by setting as an env variable
|
||||
FONTS_CONF_DENY_VF ?= $(HOME)/deny-vf
|
||||
|
||||
ifeq ($(findstring 1, $(KBUILD_VERBOSE)),)
|
||||
SPHINXOPTS += "-q"
|
||||
endif
|
||||
|
|
@ -151,10 +155,11 @@ pdfdocs:
|
|||
|
||||
else # HAVE_PDFLATEX
|
||||
|
||||
pdfdocs: DENY_VF = XDG_CONFIG_HOME=$(FONTS_CONF_DENY_VF)
|
||||
pdfdocs: latexdocs
|
||||
@$(srctree)/scripts/sphinx-pre-install --version-check
|
||||
$(foreach var,$(SPHINXDIRS), \
|
||||
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit; \
|
||||
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" $(DENY_VF) -C $(BUILDDIR)/$(var)/latex || sh $(srctree)/scripts/check-variable-fonts.sh || exit; \
|
||||
mkdir -p $(BUILDDIR)/$(var)/pdf; \
|
||||
mv $(subst .tex,.pdf,$(wildcard $(BUILDDIR)/$(var)/latex/*.tex)) $(BUILDDIR)/$(var)/pdf/; \
|
||||
)
|
||||
|
|
|
|||
|
|
@ -1572,6 +1572,15 @@ PAGE_SIZE multiple when read back.
|
|||
pglazyfreed (npn)
|
||||
Amount of reclaimed lazyfree pages
|
||||
|
||||
zswpin
|
||||
Number of pages moved in to memory from zswap.
|
||||
|
||||
zswpout
|
||||
Number of pages moved out of memory to zswap.
|
||||
|
||||
zswpwb
|
||||
Number of pages written from zswap to swap.
|
||||
|
||||
thp_fault_alloc (npn)
|
||||
Number of transparent hugepages which were allocated to satisfy
|
||||
a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
|
||||
|
|
|
|||
|
|
@ -67,8 +67,8 @@ arg4:
|
|||
will be performed for all tasks in the task group of ``pid``.
|
||||
|
||||
arg5:
|
||||
userspace pointer to an unsigned long for storing the cookie returned by
|
||||
``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
|
||||
userspace pointer to an unsigned long long for storing the cookie returned
|
||||
by ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
|
||||
|
||||
In order for a process to push a cookie to, or pull a cookie from a process, it
|
||||
is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the
|
||||
|
|
|
|||
|
|
@ -135,7 +135,7 @@ and does not want to suffer the performance impact, one can always
|
|||
disable the mitigation with spec_rstack_overflow=off.
|
||||
|
||||
Similarly, 'Mitigation: IBPB' is another full mitigation type employing
|
||||
an indrect branch prediction barrier after having applied the required
|
||||
an indirect branch prediction barrier after having applied the required
|
||||
microcode patch for one's system. This mitigation comes also at
|
||||
a performance cost.
|
||||
|
||||
|
|
|
|||
|
|
@ -4173,13 +4173,11 @@
|
|||
|
||||
page_alloc.shuffle=
|
||||
[KNL] Boolean flag to control whether the page allocator
|
||||
should randomize its free lists. The randomization may
|
||||
be automatically enabled if the kernel detects it is
|
||||
running on a platform with a direct-mapped memory-side
|
||||
cache, and this parameter can be used to
|
||||
override/disable that behavior. The state of the flag
|
||||
can be read from sysfs at:
|
||||
should randomize its free lists. This parameter can be
|
||||
used to enable/disable page randomization. The state of
|
||||
the flag can be read from sysfs at:
|
||||
/sys/module/page_alloc/parameters/shuffle.
|
||||
This parameter is only available if CONFIG_SHUFFLE_PAGE_ALLOCATOR=y.
|
||||
|
||||
page_owner= [KNL,EARLY] Boot-time page_owner enabling option.
|
||||
Storage of the information about who allocated
|
||||
|
|
@ -7353,7 +7351,7 @@
|
|||
This can be changed after boot by writing to the
|
||||
matching /sys/module/workqueue/parameters file. All
|
||||
workqueues with the "default" affinity scope will be
|
||||
updated accordignly.
|
||||
updated accordingly.
|
||||
|
||||
workqueue.debug_force_rr_cpu
|
||||
Workqueue used to implicitly guarantee that work
|
||||
|
|
|
|||
|
|
@ -308,7 +308,7 @@ limited by the ``advisor_max_cpu`` parameter. In addition there is also the
|
|||
``advisor_target_scan_time`` parameter. This parameter sets the target time to
|
||||
scan all the KSM candidate pages. The parameter ``advisor_target_scan_time``
|
||||
decides how aggressive the scan time advisor scans candidate pages. Lower
|
||||
values make the scan time advisor to scan more aggresively. This is the most
|
||||
values make the scan time advisor to scan more aggressively. This is the most
|
||||
important parameter for the configuration of the scan time advisor.
|
||||
|
||||
The initial value and the maximum value can be changed with
|
||||
|
|
|
|||
|
|
@ -42,12 +42,12 @@ The important basics
|
|||
--------------------
|
||||
|
||||
|
||||
What is a "regression" and what is the "no regressions rule"?
|
||||
What is a "regression" and what is the "no regressions" rule?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It's a regression if some application or practical use case running fine with
|
||||
one Linux kernel works worse or not at all with a newer version compiled using a
|
||||
similar configuration. The "no regressions rule" forbids this to take place; if
|
||||
similar configuration. The "no regressions" rule forbids this to take place; if
|
||||
it happens by accident, developers that caused it are expected to quickly fix
|
||||
the issue.
|
||||
|
||||
|
|
@ -173,7 +173,7 @@ Additional details about regressions
|
|||
------------------------------------
|
||||
|
||||
|
||||
What is the goal of the "no regressions rule"?
|
||||
What is the goal of the "no regressions" rule?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Users should feel safe when updating kernel versions and not have to worry
|
||||
|
|
@ -199,8 +199,8 @@ Exceptions to this rule are extremely rare; in the past developers almost always
|
|||
turned out to be wrong when they assumed a particular situation was warranting
|
||||
an exception.
|
||||
|
||||
Who ensures the "no regressions" is actually followed?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Who ensures the "no regressions" rule is actually followed?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The subsystem maintainers should take care of that, which are watched and
|
||||
supported by the tree maintainers -- e.g. Linus Torvalds for mainline and
|
||||
|
|
|
|||
|
|
@ -173,7 +173,7 @@ When accessing IDE registers with A6=1 (for example $84x),
|
|||
the timing will always be mode 0 8-bit compatible, no matter
|
||||
what you have selected in the speed register:
|
||||
|
||||
781ns select, IOR/IOW after 4 clock cycles (=314ns) aktive.
|
||||
781ns select, IOR/IOW after 4 clock cycles (=314ns) active.
|
||||
|
||||
All the timings with a very short select-signal (the 355ns
|
||||
fast accesses) depend on the accelerator card used in the
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ Chapter 36. Coprocessor services
|
|||
submissions until they succeed; waiting for an outstanding CCB to complete is not necessary, and would
|
||||
not be a guarantee that a future submission would succeed.
|
||||
|
||||
The availablility of DAX coprocessor command service is indicated by the presence of the DAX virtual
|
||||
The availability of DAX coprocessor command service is indicated by the presence of the DAX virtual
|
||||
device node in the guest MD (Section 8.24.17, “Database Analytics Accelerators (DAX) virtual-device
|
||||
node”).
|
||||
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ Note this example does not include the sigaltstack preparation.
|
|||
Dynamic features in signal frames
|
||||
---------------------------------
|
||||
|
||||
Dynamcally enabled features are not written to the signal frame upon signal
|
||||
Dynamically enabled features are not written to the signal frame upon signal
|
||||
entry if the feature is in its initial configuration. This differs from
|
||||
non-dynamic features which are always written regardless of their
|
||||
configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
|
||||
|
|
|
|||
|
|
@ -203,13 +203,33 @@ setting the DMA mask fails. In this manner, if a user of your driver reports
|
|||
that performance is bad or that the device is not even detected, you can ask
|
||||
them for the kernel messages to find out exactly why.
|
||||
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
The 24-bit addressing device would do something like this::
|
||||
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(24))) {
|
||||
dev_warn(dev, "mydev: No suitable DMA available\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))
|
||||
|
||||
dma_set_mask_and_coherent() never return fail when DMA_BIT_MASK(64). Typical
|
||||
error code like::
|
||||
|
||||
/* Wrong code */
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)))
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))
|
||||
|
||||
dma_set_mask_and_coherent() will never return failure when bigger than 32.
|
||||
So typical code like::
|
||||
|
||||
/* Recommended code */
|
||||
if (support_64bit)
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
|
||||
else
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
|
||||
|
||||
If the device only supports 32-bit addressing for descriptors in the
|
||||
coherent allocations, but supports full 64-bits for streaming mappings
|
||||
it would look like this::
|
||||
|
|
|
|||
|
|
@ -18,7 +18,7 @@ exceptions`_, `NMI and NMI-like exceptions`_.
|
|||
Non-instrumentable code - noinstr
|
||||
---------------------------------
|
||||
|
||||
Most instrumentation facilities depend on RCU, so intrumentation is prohibited
|
||||
Most instrumentation facilities depend on RCU, so instrumentation is prohibited
|
||||
for entry code before RCU starts watching and exit code after RCU stops
|
||||
watching. In addition, many architectures must save and restore register state,
|
||||
which means that (for example) a breakpoint in the breakpoint entry code would
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
Printk Index
|
||||
============
|
||||
|
||||
There are many ways how to monitor the state of the system. One important
|
||||
There are many ways to monitor the state of the system. One important
|
||||
source of information is the system log. It provides a lot of information,
|
||||
including more or less important warnings and error messages.
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ their own wrappers adding __printk_index_emit().
|
|||
|
||||
Only few subsystem specific wrappers have been updated so far,
|
||||
for example, dev_printk(). As a result, the printk formats from
|
||||
some subsystes can be missing in the printk index.
|
||||
some subsystems can be missing in the printk index.
|
||||
|
||||
|
||||
Subsystem specific prefix
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ DESCRIPTION
|
|||
***********
|
||||
|
||||
|
||||
Convert a C header or source file (C_FILE), into a ReStructured Text
|
||||
Convert a C header or source file (C_FILE), into a reStructuredText
|
||||
included via ..parsed-literal block with cross-references for the
|
||||
documentation files that describe the API. It accepts an optional
|
||||
EXCEPTIONS_FILE with describes what elements will be either ignored or
|
||||
|
|
|
|||
|
|
@ -462,7 +462,7 @@ statements is reduced. This is also reflected in the assembly code.
|
|||
Analysis 3
|
||||
==========
|
||||
|
||||
Very weird. Guess it has to do with caching or instruction parallellism
|
||||
Very weird. Guess it has to do with caching or instruction parallelism
|
||||
or so. I also tried on an eeePC (Celeron, clocked at 900 Mhz). Interesting
|
||||
observation was that this one is only 30% slower (according to time)
|
||||
executing the code as my 3Ghz D920 processor.
|
||||
|
|
|
|||
|
|
@ -259,7 +259,7 @@ attributes for Serial Attached SCSI, a variant of SATA aimed at large
|
|||
high-end systems.
|
||||
|
||||
The SAS transport class contains common code to deal with SAS HBAs, an
|
||||
aproximated representation of SAS topologies in the driver model, and
|
||||
approximated representation of SAS topologies in the driver model, and
|
||||
various sysfs attributes to expose these topologies and management
|
||||
interfaces to userspace.
|
||||
|
||||
|
|
|
|||
|
|
@ -422,7 +422,7 @@ USBDEVFS_CONNECTINFO
|
|||
|
||||
USBDEVFS_GET_SPEED
|
||||
Returns the speed of the device. The speed is returned as a
|
||||
nummerical value in accordance with enum usb_device_speed
|
||||
numerical value in accordance with enum usb_device_speed
|
||||
|
||||
File modification time is not updated by this request.
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ The expected flow for the consumers:
|
|||
can be enabled for the device.
|
||||
2. Call `amd_wbrf_register_notifier` to register for notification
|
||||
of frequency band change(add or remove) from other producers.
|
||||
3. Call the `amd_wbrf_retrieve_freq_band` initally to retrieve
|
||||
3. Call the `amd_wbrf_retrieve_freq_band` initially to retrieve
|
||||
current active frequency bands considering some producers may broadcast
|
||||
such information before the consumer is up.
|
||||
4. On receiving a notification for frequency band change, run
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ For our purposes all operations fall in 6 classes:
|
|||
* decide which of the source and target need to be locked.
|
||||
The source needs to be locked if it's a non-directory, target - if it's
|
||||
a non-directory or about to be removed.
|
||||
* take the locks that need to be taken (exlusive), in inode pointer order
|
||||
* take the locks that need to be taken (exclusive), in inode pointer order
|
||||
if need to take both (that can happen only when both source and target
|
||||
are non-directories - the source because it wouldn't need to be locked
|
||||
otherwise and the target because mixing directory and non-directory is
|
||||
|
|
@ -234,7 +234,7 @@ among the children, in some order. But that is also impossible, since
|
|||
neither of the children is a descendent of another.
|
||||
|
||||
That concludes the proof, since the set of operations with the
|
||||
properties requiered for a minimal deadlock can not exist.
|
||||
properties required for a minimal deadlock can not exist.
|
||||
|
||||
Note that the check for having a common ancestor in cross-directory
|
||||
rename is crucial - without it a deadlock would be possible. Indeed,
|
||||
|
|
|
|||
|
|
@ -858,7 +858,7 @@ be misspelled d_alloc_anon().
|
|||
|
||||
**mandatory**
|
||||
|
||||
[should've been added in 2016] stale comment in finish_open() nonwithstanding,
|
||||
[should've been added in 2016] stale comment in finish_open() notwithstanding,
|
||||
failure exits in ->atomic_open() instances should *NOT* fput() the file,
|
||||
no matter what. Everything is handled by the caller.
|
||||
|
||||
|
|
@ -989,7 +989,7 @@ This mechanism would only work for a single device so the block layer couldn't
|
|||
find the owning superblock of any additional devices.
|
||||
|
||||
In the old mechanism reusing or creating a superblock for a racing mount(2) and
|
||||
umount(2) relied on the file_system_type as the holder. This was severly
|
||||
umount(2) relied on the file_system_type as the holder. This was severely
|
||||
underdocumented however:
|
||||
|
||||
(1) Any concurrent mounter that managed to grab an active reference on an
|
||||
|
|
|
|||
|
|
@ -107,7 +107,7 @@ Other documentation
|
|||
|
||||
There are several unsorted documents that don't seem to fit on other parts
|
||||
of the documentation body, or may require some adjustments and/or conversion
|
||||
to ReStructured Text format, or are simply too old.
|
||||
to reStructuredText format, or are simply too old.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
|
|
|||
|
|
@ -80,7 +80,7 @@ to the dentry cache with::
|
|||
|
||||
Debugging options may require the minimum possible slab order to increase as
|
||||
a result of storing the metadata (for example, caches with PAGE_SIZE object
|
||||
sizes). This has a higher liklihood of resulting in slab allocation errors
|
||||
sizes). This has a higher likelihood of resulting in slab allocation errors
|
||||
in low memory situations or if there's high fragmentation of memory. To
|
||||
switch off debugging for such caches by default, use::
|
||||
|
||||
|
|
|
|||
|
|
@ -284,7 +284,7 @@ What else is there to known about regressions?
|
|||
Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot
|
||||
of other aspects you want might want to be aware of:
|
||||
|
||||
* the purpose of the "no regressions rule"
|
||||
* the purpose of the "no regressions" rule
|
||||
|
||||
* what issues actually qualify as regression
|
||||
|
||||
|
|
|
|||
|
|
@ -6,29 +6,29 @@ Everything you ever wanted to know about Linux -stable releases
|
|||
Rules on what kind of patches are accepted, and which ones are not, into the
|
||||
"-stable" tree:
|
||||
|
||||
- It or an equivalent fix must already exist in Linus' tree (upstream).
|
||||
- It must be obviously correct and tested.
|
||||
- It cannot be bigger than 100 lines, with context.
|
||||
- It must follow the
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
rules.
|
||||
- It must either fix a real bug that bothers people or just add a device ID.
|
||||
To elaborate on the former:
|
||||
- It or an equivalent fix must already exist in Linux mainline (upstream).
|
||||
- It must be obviously correct and tested.
|
||||
- It cannot be bigger than 100 lines, with context.
|
||||
- It must follow the
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
rules.
|
||||
- It must either fix a real bug that bothers people or just add a device ID.
|
||||
To elaborate on the former:
|
||||
|
||||
- It fixes a problem like an oops, a hang, data corruption, a real security
|
||||
issue, a hardware quirk, a build error (but not for things marked
|
||||
CONFIG_BROKEN), or some "oh, that's not good" issue.
|
||||
- Serious issues as reported by a user of a distribution kernel may also
|
||||
be considered if they fix a notable performance or interactivity issue.
|
||||
As these fixes are not as obvious and have a higher risk of a subtle
|
||||
regression they should only be submitted by a distribution kernel
|
||||
maintainer and include an addendum linking to a bugzilla entry if it
|
||||
exists and additional information on the user-visible impact.
|
||||
- No "This could be a problem..." type of things like a "theoretical race
|
||||
condition", unless an explanation of how the bug can be exploited is also
|
||||
provided.
|
||||
- No "trivial" fixes without benefit for users (spelling changes, whitespace
|
||||
cleanups, etc).
|
||||
- It fixes a problem like an oops, a hang, data corruption, a real security
|
||||
issue, a hardware quirk, a build error (but not for things marked
|
||||
CONFIG_BROKEN), or some "oh, that's not good" issue.
|
||||
- Serious issues as reported by a user of a distribution kernel may also
|
||||
be considered if they fix a notable performance or interactivity issue.
|
||||
As these fixes are not as obvious and have a higher risk of a subtle
|
||||
regression they should only be submitted by a distribution kernel
|
||||
maintainer and include an addendum linking to a bugzilla entry if it
|
||||
exists and additional information on the user-visible impact.
|
||||
- No "This could be a problem..." type of things like a "theoretical race
|
||||
condition", unless an explanation of how the bug can be exploited is also
|
||||
provided.
|
||||
- No "trivial" fixes without benefit for users (spelling changes, whitespace
|
||||
cleanups, etc).
|
||||
|
||||
|
||||
Procedure for submitting patches to the -stable tree
|
||||
|
|
@ -42,11 +42,11 @@ Procedure for submitting patches to the -stable tree
|
|||
|
||||
There are three options to submit a change to -stable trees:
|
||||
|
||||
1. Add a 'stable tag' to the description of a patch you then submit for
|
||||
mainline inclusion.
|
||||
2. Ask the stable team to pick up a patch already mainlined.
|
||||
3. Submit a patch to the stable team that is equivalent to a change already
|
||||
mainlined.
|
||||
1. Add a 'stable tag' to the description of a patch you then submit for
|
||||
mainline inclusion.
|
||||
2. Ask the stable team to pick up a patch already mainlined.
|
||||
3. Submit a patch to the stable team that is equivalent to a change already
|
||||
mainlined.
|
||||
|
||||
The sections below describe each of the options in more detail.
|
||||
|
||||
|
|
@ -68,82 +68,72 @@ Option 1
|
|||
********
|
||||
|
||||
To have a patch you submit for mainline inclusion later automatically picked up
|
||||
for stable trees, add the tag
|
||||
for stable trees, add this tag in the sign-off area::
|
||||
|
||||
.. code-block:: none
|
||||
Cc: stable@vger.kernel.org
|
||||
|
||||
Cc: stable@vger.kernel.org
|
||||
Use ``Cc: stable@kernel.org`` instead when fixing unpublished vulnerabilities:
|
||||
it reduces the chance of accidentally exposing the fix to the public by way of
|
||||
'git send-email', as mails sent to that address are not delivered anywhere.
|
||||
|
||||
in the sign-off area. Once the patch is mainlined it will be applied to the
|
||||
stable tree without anything else needing to be done by the author or
|
||||
subsystem maintainer.
|
||||
Once the patch is mainlined it will be applied to the stable tree without
|
||||
anything else needing to be done by the author or subsystem maintainer.
|
||||
|
||||
To sent additional instructions to the stable team, use a shell-style inline
|
||||
comment:
|
||||
To send additional instructions to the stable team, use a shell-style inline
|
||||
comment to pass arbitrary or predefined notes:
|
||||
|
||||
* To specify any additional patch prerequisites for cherry picking use the
|
||||
following format in the sign-off area:
|
||||
* Specify any additional patch prerequisites for cherry picking::
|
||||
|
||||
.. code-block:: none
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
||||
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
||||
The tag sequence has the meaning of::
|
||||
|
||||
The tag sequence has the meaning of:
|
||||
git cherry-pick a1f84a3
|
||||
git cherry-pick 1b9508f
|
||||
git cherry-pick fd21073
|
||||
git cherry-pick <this commit>
|
||||
|
||||
.. code-block:: none
|
||||
Note that for a patch series, you do not have to list as prerequisites the
|
||||
patches present in the series itself. For example, if you have the following
|
||||
patch series::
|
||||
|
||||
git cherry-pick a1f84a3
|
||||
git cherry-pick 1b9508f
|
||||
git cherry-pick fd21073
|
||||
git cherry-pick <this commit>
|
||||
patch1
|
||||
patch2
|
||||
|
||||
Note that for a patch series, you do not have to list as prerequisites the
|
||||
patches present in the series itself. For example, if you have the following
|
||||
patch series:
|
||||
where patch2 depends on patch1, you do not have to list patch1 as
|
||||
prerequisite of patch2 if you have already marked patch1 for stable
|
||||
inclusion.
|
||||
|
||||
.. code-block:: none
|
||||
* Point out kernel version prerequisites::
|
||||
|
||||
patch1
|
||||
patch2
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
|
||||
where patch2 depends on patch1, you do not have to list patch1 as
|
||||
prerequisite of patch2 if you have already marked patch1 for stable
|
||||
inclusion.
|
||||
The tag has the meaning of::
|
||||
|
||||
* For patches that may have kernel version prerequisites specify them using
|
||||
the following format in the sign-off area:
|
||||
git cherry-pick <this commit>
|
||||
|
||||
.. code-block:: none
|
||||
For each "-stable" tree starting with the specified version.
|
||||
|
||||
Cc: <stable@vger.kernel.org> # 3.3.x
|
||||
Note, such tagging is unnecessary if the stable team can derive the
|
||||
appropriate versions from Fixes: tags.
|
||||
|
||||
The tag has the meaning of:
|
||||
* Delay pick up of patches::
|
||||
|
||||
.. code-block:: none
|
||||
Cc: <stable@vger.kernel.org> # after -rc3
|
||||
|
||||
git cherry-pick <this commit>
|
||||
* Point out known problems::
|
||||
|
||||
For each "-stable" tree starting with the specified version.
|
||||
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
|
||||
|
||||
Note, such tagging is unnecessary if the stable team can derive the
|
||||
appropriate versions from Fixes: tags.
|
||||
There furthermore is a variant of the stable tag you can use to make the stable
|
||||
team's backporting tools (e.g AUTOSEL or scripts that look for commits
|
||||
containing a 'Fixes:' tag) ignore a change::
|
||||
|
||||
* To delay pick up of patches, use the following format:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
|
||||
|
||||
* For any other requests, just add a note to the stable tag. This for example
|
||||
can be used to point out known problems:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
|
||||
Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present
|
||||
|
||||
.. _option_2:
|
||||
|
||||
|
|
@ -163,17 +153,13 @@ Option 3
|
|||
Send the patch, after verifying that it follows the above rules, to
|
||||
stable@vger.kernel.org and mention the kernel versions you wish it to be applied
|
||||
to. When doing so, you must note the upstream commit ID in the changelog of your
|
||||
submission with a separate line above the commit text, like this:
|
||||
submission with a separate line above the commit text, like this::
|
||||
|
||||
.. code-block:: none
|
||||
commit <sha1> upstream.
|
||||
|
||||
commit <sha1> upstream.
|
||||
Or alternatively::
|
||||
|
||||
or alternatively:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
[ Upstream commit <sha1> ]
|
||||
[ Upstream commit <sha1> ]
|
||||
|
||||
If the submitted patch deviates from the original upstream patch (for example
|
||||
because it had to be adjusted for the older API), this must be very clearly
|
||||
|
|
@ -194,55 +180,55 @@ developers and by the relevant subsystem maintainer.
|
|||
Review cycle
|
||||
------------
|
||||
|
||||
- When the -stable maintainers decide for a review cycle, the patches will be
|
||||
sent to the review committee, and the maintainer of the affected area of
|
||||
the patch (unless the submitter is the maintainer of the area) and CC: to
|
||||
the linux-kernel mailing list.
|
||||
- The review committee has 48 hours in which to ACK or NAK the patch.
|
||||
- If the patch is rejected by a member of the committee, or linux-kernel
|
||||
members object to the patch, bringing up issues that the maintainers and
|
||||
members did not realize, the patch will be dropped from the queue.
|
||||
- The ACKed patches will be posted again as part of release candidate (-rc)
|
||||
to be tested by developers and testers.
|
||||
- Usually only one -rc release is made, however if there are any outstanding
|
||||
issues, some patches may be modified or dropped or additional patches may
|
||||
be queued. Additional -rc releases are then released and tested until no
|
||||
issues are found.
|
||||
- Responding to the -rc releases can be done on the mailing list by sending
|
||||
a "Tested-by:" email with any testing information desired. The "Tested-by:"
|
||||
tags will be collected and added to the release commit.
|
||||
- At the end of the review cycle, the new -stable release will be released
|
||||
containing all the queued and tested patches.
|
||||
- Security patches will be accepted into the -stable tree directly from the
|
||||
security kernel team, and not go through the normal review cycle.
|
||||
Contact the kernel security team for more details on this procedure.
|
||||
- When the -stable maintainers decide for a review cycle, the patches will be
|
||||
sent to the review committee, and the maintainer of the affected area of
|
||||
the patch (unless the submitter is the maintainer of the area) and CC: to
|
||||
the linux-kernel mailing list.
|
||||
- The review committee has 48 hours in which to ACK or NAK the patch.
|
||||
- If the patch is rejected by a member of the committee, or linux-kernel
|
||||
members object to the patch, bringing up issues that the maintainers and
|
||||
members did not realize, the patch will be dropped from the queue.
|
||||
- The ACKed patches will be posted again as part of release candidate (-rc)
|
||||
to be tested by developers and testers.
|
||||
- Usually only one -rc release is made, however if there are any outstanding
|
||||
issues, some patches may be modified or dropped or additional patches may
|
||||
be queued. Additional -rc releases are then released and tested until no
|
||||
issues are found.
|
||||
- Responding to the -rc releases can be done on the mailing list by sending
|
||||
a "Tested-by:" email with any testing information desired. The "Tested-by:"
|
||||
tags will be collected and added to the release commit.
|
||||
- At the end of the review cycle, the new -stable release will be released
|
||||
containing all the queued and tested patches.
|
||||
- Security patches will be accepted into the -stable tree directly from the
|
||||
security kernel team, and not go through the normal review cycle.
|
||||
Contact the kernel security team for more details on this procedure.
|
||||
|
||||
|
||||
Trees
|
||||
-----
|
||||
|
||||
- The queues of patches, for both completed versions and in progress
|
||||
versions can be found at:
|
||||
- The queues of patches, for both completed versions and in progress
|
||||
versions can be found at:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
|
||||
|
||||
- The finalized and tagged releases of all stable kernels can be found
|
||||
in separate branches per version at:
|
||||
- The finalized and tagged releases of all stable kernels can be found
|
||||
in separate branches per version at:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
|
||||
|
||||
- The release candidate of all stable kernel versions can be found at:
|
||||
- The release candidate of all stable kernel versions can be found at:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
|
||||
|
||||
.. warning::
|
||||
The -stable-rc tree is a snapshot in time of the stable-queue tree and
|
||||
will change frequently, hence will be rebased often. It should only be
|
||||
used for testing purposes (e.g. to be consumed by CI systems).
|
||||
.. warning::
|
||||
The -stable-rc tree is a snapshot in time of the stable-queue tree and
|
||||
will change frequently, hence will be rebased often. It should only be
|
||||
used for testing purposes (e.g. to be consumed by CI systems).
|
||||
|
||||
|
||||
Review committee
|
||||
----------------
|
||||
|
||||
- This is made up of a number of kernel developers who have volunteered for
|
||||
this task, and a few that haven't.
|
||||
- This is made up of a number of kernel developers who have volunteered for
|
||||
this task, and a few that haven't.
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ A summary of the ``@optname`` entries is as follows::
|
|||
destination addresses.
|
||||
|
||||
SCTP_SENDMSG_CONNECT - Initiate a connection that is generated by a
|
||||
sendmsg(2) or sctp_sendmsg(3) on a new asociation.
|
||||
sendmsg(2) or sctp_sendmsg(3) on a new association.
|
||||
|
||||
SCTP_PRIMARY_ADDR - Set local primary address.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Confidential Computing in Linux for x86 virtualization
|
|||
|
||||
.. contents:: :local:
|
||||
|
||||
By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
By: Elena Reshetova <elena.reshetova@intel.com> and Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
Motivation
|
||||
==========
|
||||
|
|
|
|||
|
|
@ -97,7 +97,6 @@ class KernelInclude(Include):
|
|||
# HINT: this is the only line I had to change / commented out:
|
||||
#path = utils.relative_path(None, path)
|
||||
|
||||
path = nodes.reprunicode(path)
|
||||
encoding = self.options.get(
|
||||
'encoding', self.state.document.settings.input_encoding)
|
||||
e_handler=self.state.document.settings.input_encoding_error_handler
|
||||
|
|
|
|||
|
|
@ -215,11 +215,12 @@
|
|||
due to the lack of suitable font families and/or the texlive-xecjk
|
||||
package.
|
||||
|
||||
If you want them, please install ``Noto Sans CJK'' font families
|
||||
along with the texlive-xecjk package by following instructions from
|
||||
If you want them, please install non-variable ``Noto Sans CJK''
|
||||
font families along with the texlive-xecjk package by following
|
||||
instructions from
|
||||
\sphinxcode{./scripts/sphinx-pre-install}.
|
||||
Having optional ``Noto Serif CJK'' font families will improve
|
||||
the looks of those translations.
|
||||
Having optional non-variable ``Noto Serif CJK'' font families will
|
||||
improve the looks of those translations.
|
||||
\end{sphinxadmonition}}
|
||||
\newcommand{\kerneldocEndSC}{}
|
||||
\newcommand{\kerneldocBeginTC}[1]{}
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Function arguments at exit
|
|||
--------------------------
|
||||
Function arguments can be accessed at exit probe using $arg<N> fetcharg. This
|
||||
is useful to record the function parameter and return value at once, and
|
||||
trace the difference of structure fields (for debuging a function whether it
|
||||
trace the difference of structure fields (for debugging a function whether it
|
||||
correctly updates the given data structure or not)
|
||||
See the :ref:`sample<fprobetrace_exit_args_sample>` below for how it works.
|
||||
|
||||
|
|
@ -248,4 +248,4 @@ mode. You can trace that changes with return probe.
|
|||
cat-143 [007] ...1. 1945.720616: vfs_open__entry: (vfs_open+0x4/0x40) mode=0x1 inode=0x0
|
||||
cat-143 [007] ...1. 1945.728263: vfs_open__exit: (do_open+0x274/0x3d0 <- vfs_open) mode=0xa800d inode=0xffff888004ada8d8
|
||||
|
||||
You can see the `file::f_mode` and `file::f_inode` are upated in `vfs_open()`.
|
||||
You can see the `file::f_mode` and `file::f_inode` are updated in `vfs_open()`.
|
||||
|
|
|
|||
|
|
@ -1968,7 +1968,7 @@ wakeup
|
|||
One common case that people are interested in tracing is the
|
||||
time it takes for a task that is woken to actually wake up.
|
||||
Now for non Real-Time tasks, this can be arbitrary. But tracing
|
||||
it none the less can be interesting.
|
||||
it nonetheless can be interesting.
|
||||
|
||||
Without function tracing::
|
||||
|
||||
|
|
|
|||
|
|
@ -322,6 +322,7 @@ architectures:
|
|||
- s390
|
||||
- parisc
|
||||
- loongarch
|
||||
- riscv
|
||||
|
||||
Configuring Kprobes
|
||||
===================
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ Function arguments at kretprobe
|
|||
-------------------------------
|
||||
Function arguments can be accessed at kretprobe using $arg<N> fetcharg. This
|
||||
is useful to record the function parameter and return value at once, and
|
||||
trace the difference of structure fields (for debuging a function whether it
|
||||
trace the difference of structure fields (for debugging a function whether it
|
||||
correctly updates the given data structure or not).
|
||||
See the :ref:`sample<fprobetrace_exit_args_sample>` in fprobe event for how
|
||||
it works.
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ the tracepoint site).
|
|||
|
||||
You can put tracepoints at important locations in the code. They are
|
||||
lightweight hooks that can pass an arbitrary number of parameters,
|
||||
which prototypes are described in a tracepoint declaration placed in a
|
||||
whose prototypes are described in a tracepoint declaration placed in a
|
||||
header file.
|
||||
|
||||
They can be used for tracing and performance accounting.
|
||||
|
|
|
|||
|
|
@ -180,9 +180,9 @@ Il valore di ritorno, se c'è, viene descritto in una sezione dedicata di nome
|
|||
se provate a formattare bene il vostro testo come nel seguente esempio::
|
||||
|
||||
* Return:
|
||||
* 0 - OK
|
||||
* -EINVAL - invalid argument
|
||||
* -ENOMEM - out of memory
|
||||
* %0 - OK
|
||||
* %-EINVAL - invalid argument
|
||||
* %-ENOMEM - out of memory
|
||||
|
||||
le righe verranno unite e il risultato sarà::
|
||||
|
||||
|
|
@ -192,8 +192,8 @@ Il valore di ritorno, se c'è, viene descritto in una sezione dedicata di nome
|
|||
utilizzare una lista ReST, ad esempio::
|
||||
|
||||
* Return:
|
||||
* * 0 - OK to runtime suspend the device
|
||||
* * -EBUSY - Device should not be runtime suspended
|
||||
* * %0 - OK to runtime suspend the device
|
||||
* * %-EBUSY - Device should not be runtime suspended
|
||||
|
||||
#) Se il vostro testo ha delle righe che iniziano con una frase seguita dai
|
||||
due punti, allora ognuna di queste frasi verrà considerata come il nome
|
||||
|
|
|
|||
|
|
@ -132,4 +132,4 @@ Documentazione varia
|
|||
|
||||
Ci sono documenti che sono difficili da inserire nell'attuale organizzazione
|
||||
della documentazione; altri hanno bisogno di essere migliorati e/o convertiti
|
||||
nel formato *ReStructured Text*; altri sono semplicamente troppo vecchi.
|
||||
nel formato *reStructuredText*; altri sono semplicamente troppo vecchi.
|
||||
|
|
|
|||
|
|
@ -462,9 +462,12 @@ linux-kernel:
|
|||
di far domande. Molti sviluppatori possono divenire impazienti con le
|
||||
persone che chiaramente non hanno svolto i propri compiti a casa.
|
||||
|
||||
- Evitate il *top-posting* (cioè la pratica di mettere la vostra risposta sopra
|
||||
alla frase alla quale state rispondendo). Ciò renderebbe la vostra risposta
|
||||
difficile da leggere e genera scarsa impressione.
|
||||
- Rispondete sotto alla porzione di righe citate, così da dare un contesto alle
|
||||
vostre risposte, e quindi renderle più leggibili (in altre parole, evitate di
|
||||
rispondere in cima, ovvero prima del testo citato). Per maggiori dettagli
|
||||
leggete :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
|
||||
<it_interleaved_replies>`.
|
||||
|
||||
|
||||
- Chiedete nella lista di discussione corretta. Linux-kernel può essere un
|
||||
punto di incontro generale, ma non è il miglior posto dove trovare
|
||||
|
|
|
|||
|
|
@ -72,6 +72,10 @@ compiti del genere. Consultate il file
|
|||
:ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>`
|
||||
per maggiori dettagli
|
||||
|
||||
Se utilizzate un programma compatibile con EditorConfig, allora alcune
|
||||
configurazioni basilari come l'indentazione e la fine delle righe verranno
|
||||
applicate automaticamente. Per maggiori informazioni consultate la pagina:
|
||||
https://editorconfig.org/
|
||||
|
||||
Livelli di astrazione
|
||||
*********************
|
||||
|
|
|
|||
|
|
@ -160,6 +160,8 @@ preparerà una richiesta nel modo in cui gli altri sviluppatori se l'aspettano,
|
|||
e verificherà che vi siate ricordati di pubblicare quelle patch su un
|
||||
server pubblico.
|
||||
|
||||
.. _development_advancedtopics_reviews_it:
|
||||
|
||||
Revisionare le patch
|
||||
--------------------
|
||||
|
||||
|
|
@ -180,6 +182,13 @@ i commenti come domande e non come critiche. Chiedere "Come viene rilasciato
|
|||
il *lock* in questo percorso?" funziona sempre molto meglio che
|
||||
"qui la sincronizzazione è sbagliata".
|
||||
|
||||
In caso di disaccordi, può essere utile chiedere una terza opinione. Se dopo
|
||||
pochi scambi la discussione raggiunge un punto morto, allora chiedete ai
|
||||
manutentori o altri revisori di partecipare esprimendo la loro opinione. Spesso
|
||||
vige un silenzio assenso per cui gli altri revisori non intervengono se non gli
|
||||
viene richiesto esplicitamente. L'opinione di più persone avrà sicuramente un
|
||||
peso maggiore.
|
||||
|
||||
Diversi sviluppatori revisioneranno il codice con diversi punti di vista.
|
||||
Alcuni potrebbero concentrarsi principalmente sullo stile del codice e se
|
||||
alcune linee hanno degli spazio bianchi di troppo. Altri si chiederanno
|
||||
|
|
@ -189,3 +198,13 @@ l'uso eccessivo di *stack*, problemi di sicurezza, duplicazione del codice
|
|||
in altri contesti, documentazione, effetti negativi sulle prestazioni, cambi
|
||||
all'ABI dello spazio utente, eccetera. Qualunque tipo di revisione è ben
|
||||
accetta e di valore, se porta ad avere un codice migliore nel kernel.
|
||||
|
||||
Non esistono requisiti particolarmente stringenti per l'uso di etichette come
|
||||
``Reviewd-by``. Tuttavia, perché la revisione sia efficace ci si aspetta un
|
||||
qualche tipo di messaggio che dica "ho verificato A, B e C nel codice che è
|
||||
appena stato inviato e mi sembra tutto in ordine". Inoltre, questo permette ai
|
||||
manutentori di prendere conoscenza circa una revisione avvenuta per davvero.
|
||||
|
||||
Per finire, la revisione delle patch può diventare un processo negativo, troppo
|
||||
focalizzato sulla ricerca dei problemi. Provate a fare qualche complimento di
|
||||
tanto in tanto, specialmente con i nuovi arrivati.
|
||||
|
|
|
|||
|
|
@ -34,13 +34,15 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils.
|
|||
====================== ================= ========================================
|
||||
GNU C 5.1 gcc --version
|
||||
Clang/LLVM (optional) 11.0.0 clang --version
|
||||
Rust (opzionale) 1.74.1 rustc --version
|
||||
bindgen (opzionale) 0.65.1 bindgen --version
|
||||
GNU make 3.81 make --version
|
||||
bash 4.2 bash --version
|
||||
binutils 2.25 ld -v
|
||||
flex 2.5.35 flex --version
|
||||
bison 2.0 bison --version
|
||||
pahole 1.16 pahole --version
|
||||
util-linux 2.10o fdformat --version
|
||||
util-linux 2.10o mount --version
|
||||
kmod 13 depmod -V
|
||||
e2fsprogs 1.41.4 e2fsck -V
|
||||
jfsutils 1.1.3 fsck.jfs -V
|
||||
|
|
@ -59,8 +61,10 @@ mcelog 0.6 mcelog --version
|
|||
iptables 1.4.2 iptables -V
|
||||
openssl & libcrypto 1.0.0 openssl version
|
||||
bc 1.06.95 bc --version
|
||||
Sphinx\ [#f1]_ 1.7 sphinx-build --version
|
||||
Sphinx\ [#f1]_ 2.4.4 sphinx-build --version
|
||||
cpio any cpio --version
|
||||
GNU tar 1.28 tar --version
|
||||
gtags (opzionale) 6.6.5 gtags --version
|
||||
====================== ================= ========================================
|
||||
|
||||
.. [#f1] Sphinx è necessario solo per produrre la documentazione del Kernel
|
||||
|
|
@ -151,6 +155,18 @@ Se la firma dei moduli è abilitata, allora vi servirà openssl per compilare il
|
|||
kernel 3.7 e successivi. Vi serviranno anche i pacchetti di sviluppo di
|
||||
openssl per compilare il kernel 4.3 o successivi.
|
||||
|
||||
Tar
|
||||
---
|
||||
|
||||
GNU Tar è necessario per accedere ai file d'intestazione del kernel usando sysfs
|
||||
(CONFIG_IKHEADERS)
|
||||
|
||||
gtags / GNU GLOBAL (opzionale)
|
||||
------------------------------
|
||||
|
||||
Il programma GNU GLOBAL versione 6.6.5, o successiva, è necessario quando si
|
||||
vuole eseguire ``make gtags`` e generare i relativi indici. Internamente si fa
|
||||
uso del parametro gtags ``-C (--directory)`` che compare in questa versione.
|
||||
|
||||
Strumenti di sistema
|
||||
********************
|
||||
|
|
@ -434,7 +450,7 @@ E2fsprogs
|
|||
JFSutils
|
||||
--------
|
||||
|
||||
- <http://jfs.sourceforge.net/>
|
||||
- <https://jfs.sourceforge.net/>
|
||||
|
||||
Reiserfsprogs
|
||||
-------------
|
||||
|
|
@ -455,7 +471,7 @@ Pcmciautils
|
|||
Quota-tools
|
||||
-----------
|
||||
|
||||
- <http://sourceforge.net/projects/linuxquota/>
|
||||
- <https://sourceforge.net/projects/linuxquota/>
|
||||
|
||||
|
||||
Microcodice Intel P6
|
||||
|
|
@ -476,7 +492,7 @@ FUSE
|
|||
mcelog
|
||||
------
|
||||
|
||||
- <http://www.mcelog.org/>
|
||||
- <https://www.mcelog.org/>
|
||||
|
||||
cpio
|
||||
----
|
||||
|
|
@ -497,7 +513,8 @@ PPP
|
|||
NFS-utils
|
||||
---------
|
||||
|
||||
- <http://sourceforge.net/project/showfiles.php?group_id=14>
|
||||
- <https://sourceforge.net/project/showfiles.php?group_id=14>
|
||||
- <https://nfs.sourceforge.net/>
|
||||
|
||||
Iptables
|
||||
--------
|
||||
|
|
@ -512,12 +529,7 @@ Ip-route2
|
|||
OProfile
|
||||
--------
|
||||
|
||||
- <http://oprofile.sf.net/download/>
|
||||
|
||||
NFS-Utils
|
||||
---------
|
||||
|
||||
- <http://nfs.sourceforge.net/>
|
||||
- <https://oprofile.sf.net/download/>
|
||||
|
||||
Documentazione del kernel
|
||||
*************************
|
||||
|
|
|
|||
|
|
@ -214,7 +214,7 @@ Non usate inutilmente le graffe dove una singola espressione è sufficiente.
|
|||
|
||||
e
|
||||
|
||||
.. code-block:: none
|
||||
.. code-block:: c
|
||||
|
||||
if (condition)
|
||||
do_this();
|
||||
|
|
@ -652,7 +652,7 @@ Quindi, potete sbarazzarvi di GNU emacs, o riconfigurarlo con valori più
|
|||
sensati. Per fare quest'ultima cosa, potete appiccicare il codice che
|
||||
segue nel vostro file .emacs:
|
||||
|
||||
.. code-block:: none
|
||||
.. code-block:: elisp
|
||||
|
||||
(defun c-lineup-arglist-tabs-only (ignored)
|
||||
"Line up argument lists by tabs, not spaces"
|
||||
|
|
@ -728,6 +728,10 @@ il testo e altre cose simili.
|
|||
Per maggiori dettagli, consultate il file
|
||||
:ref:`Documentation/translations/it_IT/process/clang-format.rst <it_clangformat>`.
|
||||
|
||||
Se utilizzate un programma compatibile con EditorConfig, allora alcune
|
||||
configurazioni basilari come l'indentazione e la fine delle righe verranno
|
||||
applicate automaticamente. Per maggiori informazioni consultate la pagina:
|
||||
https://editorconfig.org/
|
||||
|
||||
10) File di configurazione Kconfig
|
||||
----------------------------------
|
||||
|
|
@ -898,7 +902,9 @@ usare per assicurarvi che i messaggi vengano associati correttamente ai
|
|||
dispositivi e ai driver, e che siano etichettati correttamente: dev_err(),
|
||||
dev_warn(), dev_info(), e così via. Per messaggi che non sono associati ad
|
||||
alcun dispositivo, <linux/printk.h> definisce pr_info(), pr_warn(), pr_err(),
|
||||
eccetera.
|
||||
eccetera. Quando tutto funziona correttamente, non dovrebbero esserci stampe,
|
||||
per cui preferite dev_dbg/pr_debug a meno che non sia qualcosa di sbagliato
|
||||
da segnalare.
|
||||
|
||||
Tirar fuori un buon messaggio di debug può essere una vera sfida; e quando
|
||||
l'avete può essere d'enorme aiuto per risolvere problemi da remoto.
|
||||
|
|
|
|||
|
|
@ -86,7 +86,7 @@ da kcalloc().
|
|||
Se questo tipo di allocatore non è disponibile, allora dovrebbero essere usate
|
||||
le funzioni del tipo *saturate-on-overflow*::
|
||||
|
||||
bar = vmalloc(array_size(count, size));
|
||||
bar = dma_alloc_coherent(dev, array_size(count, size), &dma, GFP_KERNEL);
|
||||
|
||||
Un altro tipico caso da evitare è quello di calcolare la dimensione di una
|
||||
struttura seguita da un vettore di altre strutture, come nel seguente caso::
|
||||
|
|
|
|||
|
|
@ -85,8 +85,8 @@ relativi file di documentatione che spiegano come usarele.
|
|||
Quando un cambiamento del kernel genera anche un cambiamento nell'interfaccia
|
||||
con lo spazio utente, è raccomandabile che inviate una notifica o una
|
||||
correzione alle pagine *man* spiegando tale modifica agli amministratori di
|
||||
queste pagine all'indirizzo mtk.manpages@gmail.com, aggiungendo
|
||||
in CC la lista linux-api@vger.kernel.org.
|
||||
queste pagine all'indirizzo alx@kernel.org, aggiungendo in CC la
|
||||
lista linux-api@vger.kernel.org.
|
||||
|
||||
Di seguito una lista di file che sono presenti nei sorgente del kernel e che
|
||||
è richiesto che voi leggiate:
|
||||
|
|
@ -144,7 +144,7 @@ Di seguito una lista di file che sono presenti nei sorgente del kernel e che
|
|||
dello sviluppo di Linux ed è molto importante per le persone che arrivano
|
||||
da esperienze con altri Sistemi Operativi.
|
||||
|
||||
:ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`
|
||||
:ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`
|
||||
Se ritenete di aver trovato un problema di sicurezza nel kernel Linux,
|
||||
seguite i passaggi scritti in questo documento per notificarlo agli
|
||||
sviluppatori del kernel, ed aiutare la risoluzione del problema.
|
||||
|
|
|
|||
|
|
@ -21,19 +21,75 @@ l'accettazione delle vostre modifiche con il minimo sforzo.
|
|||
|
||||
Di seguito le guide che ogni sviluppatore dovrebbe leggere.
|
||||
|
||||
Introduzione al funzionamento dello sviluppo del kernel
|
||||
-------------------------------------------------------
|
||||
|
||||
Innanzitutto, leggete questi documenti che vi aiuteranno ad entrare nella
|
||||
comunità del kernel.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
howto
|
||||
code-of-conduct
|
||||
development-process
|
||||
submitting-patches
|
||||
submit-checklist
|
||||
|
||||
Strumenti e guide tecniche per gli sviluppatori del kernel
|
||||
----------------------------------------------------------
|
||||
|
||||
Quella che segue è una raccolta di documenti che uno sviluppatore del kernel
|
||||
Linux dovrebbe conoscere.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
changes
|
||||
programming-language
|
||||
coding-style
|
||||
maintainer-pgp-guide
|
||||
email-clients
|
||||
applying-patches
|
||||
adding-syscalls
|
||||
volatile-considered-harmful
|
||||
botching-up-ioctls
|
||||
|
||||
Politiche e dichiarazioni degli sviluppatori
|
||||
--------------------------------------------
|
||||
|
||||
Quelle che seguono rappresentano le regole che cerchiamo di seguire all'interno
|
||||
della comunità del kernel (e oltre).
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
code-of-conduct
|
||||
kernel-enforcement-statement
|
||||
kernel-driver-statement
|
||||
stable-api-nonsense
|
||||
stable-kernel-rules
|
||||
management-style
|
||||
|
||||
Gestire i bachi
|
||||
---------------
|
||||
|
||||
I bachi sono parte della nostra vita; dunque è importante che vengano trattati
|
||||
con riguardo. I documenti che seguono descrivono le nostre politiche riguardo al
|
||||
trattamento di alcune classi particolari di bachi: le regressioni e i problemi
|
||||
di sicurezza.
|
||||
|
||||
Informazioni per i manutentori
|
||||
------------------------------
|
||||
|
||||
Come trovare le persone che accetteranno le vostre modifiche.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
maintainers
|
||||
|
||||
Altri documenti
|
||||
---------------
|
||||
|
||||
Poi ci sono altre guide sulla comunità che sono di interesse per molti
|
||||
degli sviluppatori:
|
||||
|
|
@ -41,13 +97,7 @@ degli sviluppatori:
|
|||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
changes
|
||||
stable-api-nonsense
|
||||
management-style
|
||||
stable-kernel-rules
|
||||
submit-checklist
|
||||
kernel-docs
|
||||
maintainers
|
||||
|
||||
Ed infine, qui ci sono alcune guide più tecniche che son state messe qua solo
|
||||
perché non si è trovato un posto migliore.
|
||||
|
|
@ -55,11 +105,7 @@ perché non si è trovato un posto migliore.
|
|||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
applying-patches
|
||||
adding-syscalls
|
||||
magic-number
|
||||
volatile-considered-harmful
|
||||
botching-up-ioctls
|
||||
clang-format
|
||||
../riscv/patch-acceptance
|
||||
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ Procedura per sottomettere patch per i sorgenti -stable
|
|||
.. note::
|
||||
Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo
|
||||
di revisione -stable, ma dovrebbe seguire le procedure descritte in
|
||||
:ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`.
|
||||
:ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`.
|
||||
|
||||
Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
|
||||
------------------------------------------------------------------------
|
||||
|
|
|
|||
|
|
@ -349,6 +349,33 @@ Leggete Documentation/translations/it_IT/process/email-clients.rst per
|
|||
le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare
|
||||
sulle liste di discussione.
|
||||
|
||||
.. _it_interleaved_replies:
|
||||
|
||||
Rispondere alle email in riga e riducendo la citazioni
|
||||
------------------------------------------------------
|
||||
|
||||
Nelle discussioni riguardo allo sviluppo del kernel viene fortemente scoraggiato
|
||||
l'uso di risposte in cima ai messaggi di posta elettronica. Rispondere in riga
|
||||
rende le conversazioni molto più scorrevoli. Maggiori dettagli possono essere
|
||||
trovati qui: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
|
||||
|
||||
Come spesso citato nelle liste di discussione::
|
||||
|
||||
R: http://en.wikipedia.org/wiki/Top_post
|
||||
D: Dove posso trovare informazioni riguardo alle "risposte in cima"?
|
||||
R: Perché incasina il normale ordine con cui si legge un testo.
|
||||
D: Perché è così terribile rispondere in cima?
|
||||
R: Risposte in cima.
|
||||
Q: Qual è la cosa più fastidiosa nei messaggi di posta elettronica?
|
||||
|
||||
Allo stesso modo, per favore eliminate tutte le citazioni non necessarie per la
|
||||
vostra risposta. Questo permette di trovare più facilmente le risposte, e
|
||||
permette di risparmiare tempo e spazio. Per maggiori dettagli:
|
||||
http://daringfireball.net/2007/07/on_top ::
|
||||
|
||||
R: No.
|
||||
D: Dovrei includere un blocco di citazione dopo la mia risposta?
|
||||
|
||||
.. _it_resend_reminders:
|
||||
|
||||
Non scoraggiatevi - o impazientitevi
|
||||
|
|
|
|||
|
|
@ -110,7 +110,7 @@ Linux カーネルソースツリーは幅広い範囲のドキュメントを
|
|||
新しいドキュメントファイルも追加することを勧めます。
|
||||
カーネルの変更が、カーネルがユーザ空間に公開しているインターフェイスの
|
||||
変更を引き起こす場合、その変更を説明するマニュアルページのパッチや情報
|
||||
をマニュアルページのメンテナ mtk.manpages@gmail.com に送り、CC を
|
||||
をマニュアルページのメンテナ alx@kernel.org に送り、CC を
|
||||
linux-api@vger.kernel.org に送ることを勧めます。
|
||||
|
||||
以下はカーネルソースツリーに含まれている読んでおくべきファイルの一覧で
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Traducción al español
|
|||
|
||||
\kerneldocCJKoff
|
||||
|
||||
:maintainer: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:maintainer: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_disclaimer:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
NOTE:
|
||||
This is a version of Documentation/memory-barriers.txt translated into
|
||||
Spanish by Carlos Bilbao <carlos.bilbao@amd.com>. If you find any
|
||||
Spanish by Carlos Bilbao <carlos.bilbao.osdev@gmail.com>. If you find any
|
||||
difference between this document and the original file or a problem with
|
||||
the translation, please contact the maintainer of this file. Please also
|
||||
note that the purpose of this file is to be easier to read for non English
|
||||
|
|
@ -18,7 +18,7 @@ Documento original: David Howells <dhowells@redhat.com>
|
|||
Will Deacon <will.deacon@arm.com>
|
||||
Peter Zijlstra <peterz@infradead.org>
|
||||
|
||||
Traducido por: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
Traducido por: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
Nota: Si tiene alguna duda sobre la exactitud del contenido de esta
|
||||
traducción, la única referencia válida es la documentación oficial en
|
||||
inglés.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,302 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/1.Intro.rst
|
||||
:Translator: Avadhut Naik <avadhut.naik@amd.com>
|
||||
|
||||
.. _sp_development_process_intro:
|
||||
|
||||
Introducción
|
||||
============
|
||||
|
||||
Resumen ejecutivo
|
||||
-----------------
|
||||
|
||||
El resto de esta sección cubre el alcance del proceso de desarrollo del
|
||||
kernel y los tipos de frustraciones que los desarrolladores y sus
|
||||
empleadores pueden encontrar allí. Hay muchas razones por las que el
|
||||
código del kernel debe fusionarse con el kernel oficial (“mainline”),
|
||||
incluyendo la disponibilidad automática para los usuarios, el apoyo de la
|
||||
comunidad en muchas formas, y la capacidad de influir en la dirección del
|
||||
desarrollo del kernel. El código contribuido al kernel de Linux debe
|
||||
estar disponible bajo una licencia compatible con GPL.
|
||||
|
||||
:ref:`sp_development_process` introduce el proceso de desarrollo, el ciclo
|
||||
de lanzamiento del kernel y la mecánica de la "ventana de combinación"
|
||||
(merge window). Se cubren las distintas fases en el desarrollo del parche,
|
||||
la revisión y, el ciclo de fusión. Hay algunas discusiones sobre
|
||||
herramientas y listas de correo. Se anima a los desarrolladores que deseen
|
||||
comenzar con el desarrollo del kernel a encontrar y corregir errores como
|
||||
ejercicio inicial.
|
||||
|
||||
:ref:`sp_development_early_stage` cubre la planificación de proyectos en
|
||||
etapas tempranas, con énfasis en involucrar a la comunidad de desarrollo
|
||||
lo antes posible.
|
||||
|
||||
:ref:`sp_development_coding` trata sobre el proceso de codificación. Se
|
||||
discuten varios escollos encontrados por otros desarrolladores. Se cubren
|
||||
algunos requisitos para los parches, y hay una introducción a algunas de
|
||||
las herramientas que pueden ayudar a garantizar que los parches del kernel
|
||||
sean correctos.
|
||||
|
||||
:ref:`sp_development_posting` trata sobre el proceso de enviar parches para
|
||||
su revisión. Para ser tomados en serio por la comunidad de desarrollo,
|
||||
los parches deben estar correctamente formateados y descritos, y deben
|
||||
enviarse al lugar correcto. Seguir los consejos de esta sección debería
|
||||
ayudar a garantizar la mejor recepción posible para su trabajo.
|
||||
|
||||
:ref:`sp_development_followthrough` cubre lo que sucede después de publicar
|
||||
parches; el trabajo está lejos de terminar en ese momento. Trabajar con
|
||||
revisores es una parte crucial del proceso de desarrollo; esta sección
|
||||
ofrece varios consejos sobre cómo evitar problemas en esta importante
|
||||
etapa. Se advierte a los desarrolladores que no asuman que el trabajo está
|
||||
terminado cuando un parche se fusiona en mainline.
|
||||
|
||||
:ref:`sp_development_advancedtopics` introduce un par de temas “avanzados”:
|
||||
la administración de parches con git y la revisión de parches publicados
|
||||
por otros.
|
||||
|
||||
:ref:`sp_development_conclusion` concluye el documento con punteros a las
|
||||
fuentes para obtener más información sobre el desarrollo del kernel.
|
||||
|
||||
De qué trata este documento
|
||||
---------------------------
|
||||
|
||||
El kernel de Linux, con más de 8 millones de líneas de código y más de
|
||||
1000 colaboradores en cada versión, en uno de los proyectos de software
|
||||
libre más grandes y activos que existen. Desde sus humildes comienzos en
|
||||
1991, este kernel ha evolucionado hasta convertirse en el mejor componente
|
||||
del sistema operativo que se ejecuta en reproductores de música digital
|
||||
de bolsillo, PC de escritorio, las supercomputadoras más grandes que
|
||||
existen y todo tipo de sistemas intermedios. Es una solución robusta,
|
||||
eficiente, y escalable para casi cualquier situación.
|
||||
|
||||
Con el crecimiento de Linux, ha llegado un aumento en el número de
|
||||
desarrolladores (y empresas) que desean participar en su desarrollo. Los
|
||||
vendedores de hardware quieren asegurarse de que Linux sea compatible con
|
||||
sus productos, lo que hace que esos productos sean atractivos para los
|
||||
usuarios de Linux. Los vendedores de sistemas embebidos, que utilizan
|
||||
Linux como componente de un producto integrado, quieren que Linux sea lo
|
||||
más capaz y adecuado posible para tarea en cuestión. Los distribuidores
|
||||
y otros vendedores de software que basan sus productos en Linux tienen un
|
||||
claro interés en las capacidades, el rendimiento, y la fiabilidad del
|
||||
kernel de Linux. Y los usuarios finales, también, a menudo desearán
|
||||
cambiar Linux para que se adapte mejor a sus necesidades.
|
||||
|
||||
Una de las características más convincentes de Linux es que es accesible
|
||||
a estos desarrolladores; cualquier persona con las habilidades necesarias
|
||||
puede mejorar Linux e influir en la dirección de su desarrollo. Los
|
||||
productos propietarios no pueden ofrecer este tipo de apertura, que es una
|
||||
característica del proceso de software libre. Pero, en todo caso, el
|
||||
kernel es aún más libre que la mayoría de los otros proyectos de software
|
||||
libre. Un ciclo típico de desarrollo de kernel de tres meses puede
|
||||
involucrar a más de 1000 desarrolladores que trabajan para más de 100
|
||||
empresas diferentes (o sin pertenecer a ninguna empresa).
|
||||
|
||||
Trabajar con la comunidad de desarrollo del kernel no es especialmente
|
||||
difícil. Pero, a pesar de eso, muchos colaboradores potenciales han
|
||||
experimentado dificultades al tratar de hacer el trabajo del kernel. La
|
||||
comunidad del kernel ha desarrollado sus propias formas distintivas de
|
||||
operar, lo que le permite funcionar de manera fluida (y producir un
|
||||
producto de alta calidad) en un entorno donde miles de líneas de código
|
||||
se cambian todos los días. Por lo tanto, no es sorprendente que el
|
||||
proceso de desarrollo del kernel de Linux difiera mucho de los métodos de
|
||||
desarrollo propietarios.
|
||||
|
||||
El proceso de desarrollo del kernel puede parecer extraño e intimidante
|
||||
para los nuevos desarrolladores, pero hay buenas razones y una sólida
|
||||
experiencia detrás de él. Un desarrollador que no entienda las formas de
|
||||
la comunidad del kernel (o, peor aún, que intente burlarse o eludirlas)
|
||||
tendrá una experiencia frustrante por delante. La comunidad de
|
||||
desarrollo, si bien es servicial para aquellos que están tratando de
|
||||
aprender, tiene poco tiempo para aquellos que no escuchan o que no se
|
||||
preocupan por el proceso de desarrollo.
|
||||
|
||||
Se espera que quienes lean este documento puedan evitar esa experiencia
|
||||
frustrante. Hay mucho material aquí, pero el esfuerzo que implica leerlo
|
||||
será recompensado en poco tiempo. La comunidad de desarrollo siempre
|
||||
necesita desarrolladores que ayudan a mejorar el kernel; el siguiente
|
||||
texto debería ayudarle – o a quienes trabajan para usted, a unirse a
|
||||
nuestra comunidad.
|
||||
|
||||
Créditos
|
||||
--------
|
||||
|
||||
Este documento fue escrito por Jonathan Corbet, corbet@lwn.net. Ha sido
|
||||
mejorado por los comentarios de Johannes Berg, James Berry, Alex Chiang,
|
||||
Roland Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur
|
||||
Marsh, Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata y
|
||||
Jochen Voß.
|
||||
Este trabajo fue respaldado por la Fundación Linux; gracias especialmente
|
||||
a Amanda McPherson, quien reconoció el valor de este esfuerzo e hizo que
|
||||
todo sucediera.
|
||||
|
||||
Importancia de integrar el código en el mainline
|
||||
------------------------------------------------
|
||||
|
||||
Algunas empresas y desarrolladores ocasionalmente se preguntan por qué
|
||||
deberían molestarse en aprender cómo trabajar con la comunidad del
|
||||
kernel y obtener su código en el kernel mainline (el “mainline” es el
|
||||
kernel mantenido por Linus Torvalds y utilizado como base por los
|
||||
distribuidores de Linux. A corto plazo, contribuir con código puede
|
||||
parecer un gasto evitable; parece más fácil mantener el código separado
|
||||
y dar soporte a los usuarios directamente. La verdad del asunto es que
|
||||
mantener el código separado (“fuera del árbol”) es pan para hoy y hambre
|
||||
para mañana.
|
||||
|
||||
Para ilustrar los costos del código fuera-del-árbol, aquí hay algunos
|
||||
aspectos relevantes del proceso de desarrollo del kernel. La mayoría de
|
||||
estos se discutirán con mayor detalle más adelante en este documento.
|
||||
Considerar:
|
||||
|
||||
- El código que se ha fusionado con el kernel mainline está disponible
|
||||
para todos los usuarios de Linux. Estará presente automáticamente en
|
||||
todas las distribuciones que lo habiliten. No hay necesidad de discos
|
||||
de controladores, descargas, o las molestias de admitir múltiples
|
||||
versiones de múltiples distribuciones; todo simplemente funciona, para
|
||||
el desarrollador y para el usuario. La incorporación al mainline
|
||||
resuelve un gran número de problemas de distribución y soporte.
|
||||
|
||||
- Mientras los desarrolladores del kernel se esfuerzan por mantener una
|
||||
interfaz estable para el espacio de usuario, la API interna de kernel
|
||||
está en constante cambio. La falta de una interfaz interna estable es
|
||||
una decisión deliberada de diseño; permite realizar mejoras
|
||||
fundamentales en cualquier momento y da como resultado un código de
|
||||
mayor calidad. Pero uno resultado de esa política es que cualquier
|
||||
código fuera-del-árbol requiere un mantenimiento constante si va a
|
||||
funcionar con los nuevos kernels. Mantener el código fuera-del-árbol
|
||||
requiere una cantidad significativa de trabajo sólo para que ese código
|
||||
siga funcionando.
|
||||
|
||||
En su lugar, el código en el mainline no requiere este trabajo como
|
||||
resultado de una regla simple que requiere que cualquier desarrollador
|
||||
que realice un cambio en la API también corrija cualquier código que
|
||||
se rompa como resultado de ese cambio. Así que, el código fusionado en
|
||||
el mainline tiene costos de mantenimiento significativamente más bajos.
|
||||
|
||||
- Más allá de eso, el código que está en el kernel a menudo será
|
||||
mejorado por otros desarrolladores. Resultados sorprendentes pueden
|
||||
provenir de capacitar a su comunidad de usuarios y clientes para mejorar
|
||||
su producto.
|
||||
|
||||
- El código del kernel se somete a revisión, tanto antes como después
|
||||
de fusionarse con el mainline. No importa cuán fuertes sean las
|
||||
habilidades del desarrollador original, este proceso de revisión
|
||||
invariablemente encuentra formas en las que se puede mejorar el código.
|
||||
A menudo la revisión encuentra errores graves y problemas de seguridad.
|
||||
Esto es especialmente cierto para el código que se ha desarrollado en
|
||||
un entorno cerrado; dicho código se beneficia fuertemente de la
|
||||
revisión por desarrolladores externos. El código fuera-del-árbol es
|
||||
de menor calidad.
|
||||
|
||||
- La participación en el proceso de desarrollo es su manera de influir en
|
||||
la dirección del desarrollo del kernel. Los usuarios que se quejan
|
||||
desde el sofa son escuchados, pero los desarrolladores activos tienen
|
||||
una voz más fuerte – y la capacidad de implementar cambios que hacen
|
||||
que el kernel funcione mejor para sus necesidades.
|
||||
|
||||
- Cuando el código se mantiene por separado, siempre existe la posibilidad
|
||||
de que un tercero contribuya a una implementación diferente de una
|
||||
característica similar. Si eso sucede, conseguir que su código
|
||||
fusionado será mucho más difícil – hasta el punto de la imposibilidad.
|
||||
Entonces se enfrentará a las desagradables alternativas de (1) mantener
|
||||
una característica no estándar fuera del árbol indefinidamente, o
|
||||
(2) abandonar su código y migrar sus usuarios a la versión en el árbol.
|
||||
|
||||
- La contribución del código es la acción fundamental que hace que todo
|
||||
el proceso funcione. Al contribuir con su código, puede agregar nuevas
|
||||
funcionalidades al kernel y proporcionar capacidades y ejemplos que son
|
||||
útiles para otros desarrolladores del kernel. Si ha desarrollado código
|
||||
para Linux (o está pensando en hacerlo), claramente tiene un interés
|
||||
en el éxito continuo de esta plataforma; contribuir con código es una
|
||||
de las mejores maneras de ayudar a garantizar ese éxito.
|
||||
|
||||
Todo el razonamiento anterior se aplica a cualquier código de kernel
|
||||
fuera-del-árbol, incluido el código que se distribuye en forma propietaria
|
||||
y únicamente en binario. Sin embargo, hay factores adicionales que deben
|
||||
tenerse en cuenta antes de considerar cualquier tipo de distribución de
|
||||
código de kernel únicamente en binario. Estos incluyen:
|
||||
|
||||
- Las cuestiones legales en torno a la distribución de módulos
|
||||
propietarios del kernel son, en el mejor de los casos, confusas;
|
||||
bastantes titulares de derechos de autor del kernel creen que la
|
||||
mayoría de los módulos binarios son productos derivados del kernel y
|
||||
que, como resultado, su distribución es una violación de la licencia
|
||||
Pública General de GNU (sobre la que se dirá más adelante). El autor
|
||||
de este texto no es abogado, y nada en este documento puede considerarse
|
||||
asesoramiento legal. Solo los tribunales pueden determinar el verdadero
|
||||
estatus legal de los módulos de código cerrado. Pero la incertidumbre
|
||||
que acecha a esos módulos está ahí a pesar de todo.
|
||||
|
||||
- Los módulos binarios aumentan enormemente la dificultad de depurar
|
||||
problemas del kernel, hasta el punto de que la mayoría de los
|
||||
desarrolladores del kernel ni siquiera lo intentarán. Por lo tanto,
|
||||
la distribución de módulos únicamente en binario hará que sea más
|
||||
difícil para sus usuarios obtener soporte de la comunidad.
|
||||
|
||||
- El soporte también es más difícil para los distribuidores de módulos
|
||||
únicamente en binario, que deben proporcionar una versión del módulo
|
||||
para cada distribución y cada versión del kernel que deseen apoyar.
|
||||
Podría requerir docenas de compilaciones de un solo módulo para
|
||||
proporcionar una cobertura razonablemente completa, y sus usuarios
|
||||
tendrán que actualizar su módulo por separado cada vez que
|
||||
actualicen su kernel.
|
||||
|
||||
- Todo lo que se dijo anteriormente sobre la revisión de código se aplica
|
||||
doblemente al código cerrado. Dado que este código no está disponible
|
||||
en absoluto, no puede haber sido revisado por la comunidad y, sin duda,
|
||||
tendrá serios problemas.
|
||||
|
||||
Los fabricantes de sistemas embebidos, en particular, pueden verse
|
||||
tentados a ignorar gran parte de lo que se ha dicho en esta sección
|
||||
creyendo que están enviando un producto autónomo que utiliza una
|
||||
versión de kernel congelada y no requiere más desarrollo después de su
|
||||
lanzamiento. Este argumento desaprovecha el valor de la revisión
|
||||
generalizad del código y el valor de permitir que sus usuarios agreguen
|
||||
capacidades a su producto. Pero estos productos también tienen una vida
|
||||
comercial limitada, después de la cual se debe lanzar una nueva versión.
|
||||
En ese punto, los vendedores cuyo código esté en el mainline y bien
|
||||
mantenido estarán en una posición mucho mejor para preparar el nuevo
|
||||
producto rápidamente para el mercado.
|
||||
|
||||
Licencias
|
||||
---------
|
||||
|
||||
El código se contribuye al kernel de Linux bajo varias licencias, pero
|
||||
todo el código debe ser compatible con la versión 2 de la Licencia
|
||||
Pública General de GNU (GPLv2), que cubre la distribución del kernel. En
|
||||
la práctica, esto significa que todas las contribuciones de código están
|
||||
cubiertas ya sea por la GPLv2 (con, opcionalmente, un lenguaje que permite
|
||||
la distribución en versiones posteriores de la GPL) o por la licencia BSD
|
||||
de tres cláusulas. Cualquier contribución que no esté cubierta por una
|
||||
licencia compatible no será aceptada en el kernel.
|
||||
|
||||
No se requieren (ni se solicitan) cesiones de derechos de autor para el
|
||||
código aportado al kernel. Todo el código fusionado en el kernel
|
||||
mainline conserva su propiedad original; como resultado, el kernel ahora
|
||||
tiene miles de propietarios.
|
||||
|
||||
Una implicación de esta estructura de propiedad es que cualquier intento
|
||||
de cambiar la licencia del kernel está condenado a un fracaso casi seguro.
|
||||
Hay pocos escenarios prácticos en los que se pueda obtener el acuerdo de
|
||||
todos los titulares de derechos de autor (o eliminar su código del
|
||||
kernel). Así que, en particular, no hay perspectivas de una migración a
|
||||
la versión 3 de la GPL en un futuro previsible.
|
||||
|
||||
Es imperativo que todo el código aportado al kernel sea legítimamente
|
||||
software libre. Por esa razón, no se aceptará código de colaboradores
|
||||
anónimos (o seudónimos). Todos los colaboradores están obligados a
|
||||
“firmar” su código, indicando que el código puede ser distribuido con
|
||||
el kernel bajo la GPL. El código que no ha sido licenciado como software
|
||||
libre por su propietario, o que corre el riesgo de crear problemas
|
||||
relacionadas con los derechos de autor para el kernel (como el código que
|
||||
se deriva de esfuerzos de ingeniería inversa que carecen de las garantías
|
||||
adecuadas) no puede ser contribuido.
|
||||
|
||||
Las preguntas sobre cuestiones relacionadas con los derechos de autor son
|
||||
comunes en las listas de correo de desarrollo de Linux. Normalmente, estas
|
||||
preguntas no recibirán escasez de respuestas, pero se debe tener en cuenta
|
||||
que las personas que responden a esas preguntas no son abogados y no
|
||||
pueden proporcionar consejo legal. Si tiene preguntas legales relacionadas
|
||||
con el código fuente de Linux, no hay sustituto para hablar con un abogado
|
||||
que entienda este campo. Confiar en las respuestas obtenidas en listas
|
||||
técnicas de correo es un asunto arriesgado.
|
||||
|
|
@ -0,0 +1,542 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/2.Process.rst
|
||||
:Translator: Avadhut Naik <avadhut.naik@amd.com>
|
||||
|
||||
.. _sp_development_process:
|
||||
|
||||
Cómo funciona el proceso de desarrollo
|
||||
======================================
|
||||
|
||||
El desarrollo del kernel de Linux a principios de la década de 1990 fue
|
||||
un asunto relajado, con un número relativamente pequeño de usuarios y
|
||||
desarrolladores involucrados. Con una base de usuarios en los millones y
|
||||
alrededor de 2,000 desarrolladores involucrados durante un año, el kernel
|
||||
ha tenido que adaptar varios procesos para mantener el desarrollo sin
|
||||
problemas. Se requiere una comprensión solida de cómo funciona el proceso
|
||||
para ser una parte efectiva del mismo.
|
||||
|
||||
El panorama general
|
||||
-------------------
|
||||
|
||||
Los desarrolladores del kernel utilizan un proceso de lanzamiento basado
|
||||
en el tiempo de manera flexible, con uno nuevo lanzamiento principal del
|
||||
kernel ocurriendo cada dos o tres meses. El historial reciente de
|
||||
lanzamientos se ve así:
|
||||
|
||||
====== ==================
|
||||
5.0 Marzo 3, 2019
|
||||
5.1 Mayo 5, 2019
|
||||
5.2 Julio 7, 2019
|
||||
5.3 Septiembre 15, 2019
|
||||
5.4 Noviembre 24, 2019
|
||||
5.5 Enero 6, 2020
|
||||
====== ==================
|
||||
|
||||
Cada lanzamiento 5.x es un lanzamiento principal del kernel con nuevas
|
||||
características, cambios internos en la API y más. Un lanzamiento típico
|
||||
puede contener alrededor de 13,000 conjuntos de cambios incluyendo en
|
||||
varias centenas de miles de líneas de código. 5.x es la vanguardia del
|
||||
desarrollo del kernel de Linux; el kernel utiliza un modelo de desarrollo
|
||||
continuo que está integrando continuamente cambios importantes.
|
||||
|
||||
Se sigue una disciplina relativamente sencilla con respecto a la fusión
|
||||
de parches para cada lanzamiento. Al comienzo de cada ciclo de desarrollo,
|
||||
se dice que la "merge window" (ventana de fusión) está abierta. En ese
|
||||
momento, el código que se considera lo suficientemente estable (y que es
|
||||
aceptado por la comunidad de desarrollo) se fusiona en el kernel mainline.
|
||||
La mayor parte de los cambios para un nuevo ciclo de desarrollo (y todos
|
||||
los cambios principales) se fusionarán durante este tiempo, a un ritmo
|
||||
cercano a los 1,000 cambios (“parches” o “conjuntos de cambios”) por
|
||||
día.
|
||||
|
||||
(Aparte, vale la pena señalar que los cambios integrados durante la
|
||||
ventana de fusión no surgen de la nada; han sido recolectados, probados
|
||||
y montados con anticipación. Como funciona ese proceso se describirá en
|
||||
detalle más adelante).
|
||||
|
||||
La ventana de fusión dura aproximadamente dos semanas. Al final de este
|
||||
tiempo, Linux Torvalds declarará que la ventana está cerrada y publicará
|
||||
el primero de los kernels “rc”. Para el kernel destinado a ser 5.6, por
|
||||
ejemplo, el lanzamiento al final de la ventana de fusión se llamará
|
||||
5.6-rc1. El lanzamiento -rc1 señala que el tiempo para fusionar nuevas
|
||||
características ha pasado y que el tiempo para estabilizar el siguiente
|
||||
kernel ha comenzado.
|
||||
|
||||
Durante las próximas seis a diez semanas, solo los parches que solucionen
|
||||
problemas deben enviarse al mainline. En ocasiones, se permitirá un cambio
|
||||
más significativo, pero tales ocasiones son raras; los desarrolladores que
|
||||
intentan fusionar nuevas características fuera de la ventana de fusión
|
||||
suelen recibir una recepción poco amistosa. Como regla general, si se
|
||||
pierde la ventana de fusión de una característica determinada, lo mejor
|
||||
que puede hacer es esperar al siguiente ciclo de desarrollo. (Se hace una
|
||||
excepción ocasional para los drivers de hardware que no se admitía
|
||||
anteriormente; si no afectan a ningún código en árbol, no pueden causar
|
||||
regresiones y debería ser seguro agregarlos en cualquier momento).
|
||||
|
||||
A medida que las correcciones se abren paso en el mainline, la tasa de
|
||||
parches se ralentizará con el tiempo. Linus lanza nuevos kernels -rc
|
||||
aproximadamente una vez a la semana; una serie normal llegará a algún
|
||||
punto entre -rc6 y -rc9 antes de que se considere que el kernel es
|
||||
suficientemente estable y realice el lanzamiento final. En ese momento,
|
||||
todo el proceso vuelve a empezar.
|
||||
|
||||
Como ejemplo, así fue el ciclo de desarrollo de 5.4 (todas las fechas son
|
||||
de 2019):
|
||||
|
||||
============== =======================================
|
||||
Septiembre 15 5.3 lanzamiento estable
|
||||
Septiembre 30 5.4-rc1, la ventana de fusion se cierra
|
||||
Octubre 6 5.4-rc2
|
||||
Octubre 13 5.4-rc3
|
||||
Octubre 20 5.4-rc4
|
||||
Octubre 27 5.4-rc5
|
||||
Noviembre 3 5.4-rc6
|
||||
Noviembre 10 5.4-rc7
|
||||
Noviembre 17 5.4-rc8
|
||||
Noviembre 24 5.4 lanzamiento estable
|
||||
============== =======================================
|
||||
|
||||
¿Cómo deciden los desarrolladores cuándo cerrar el ciclo de desarrollo
|
||||
y crear el lanzamiento estable? La métrica más significativa utilizada
|
||||
es la lista de regresiones de lanzamientos anteriores. Ningunos errores
|
||||
son bienvenidos, pero aquellos que rompen sistemas que funcionaron en el
|
||||
pasado se consideran especialmente graves. Por esta razón, los parches
|
||||
que causan regresiones se ven con malos ojos y es bastante probable que
|
||||
se reviertan durante el periodo de estabilización.
|
||||
|
||||
El objetivo de los desarrolladores es corregir todas las regresiones
|
||||
conocidas antes de que se realice el lanzamiento estable. En el mundo
|
||||
real, este tipo de perfección es difícil de lograr; hay demasiados
|
||||
variables en un proyecto de este tamaño. Llega un punto en el que
|
||||
retrasar el lanzamiento final solo empeora el problema; la pila de cambios
|
||||
que esperan la siguiente ventana de fusión crecerá, creando aún más
|
||||
regresiones la próxima vez. Por lo tanto, la mayoría de los kernels 5.x
|
||||
se lanzan con un punado de regresiones conocidas, aunque, con suerte,
|
||||
ninguna de ellas es seria.
|
||||
|
||||
Una vez que se realiza un lanzamiento estable, su mantenimiento continuo
|
||||
se transfiere al “equipo estable”, actualmente encabezado por Greg
|
||||
Kroah-Hartman. El equipo estable lanzará actualizaciones ocasionales al
|
||||
lanzamiento estable utilizando el esquema de numeración 5.x.y. Para ser
|
||||
considerado para un lanzamiento de actualización, un parche debe
|
||||
(1) corregir un error significativo y (2) ya estar fusionado en el
|
||||
mainline para el siguiente kernel de desarrollo. Por lo general, los
|
||||
kernels recibirán actualizaciones estables durante un poco más de un
|
||||
ciclo de desarrollo después de su lanzamiento inicial. Así, por ejemplo,
|
||||
la historia del kernel 5.2 se veía así (todas las fechas en 2019):
|
||||
|
||||
============== ===============================
|
||||
Julio 7 5.2 lanzamiento estable
|
||||
Julio 14 5.2.1
|
||||
Julio 21 5.2.2
|
||||
Julio 26 5.2.3
|
||||
Julio 28 5.2.4
|
||||
Julio 31 5.2.5
|
||||
... ...
|
||||
Octubre 11 5.2.21
|
||||
============== ===============================
|
||||
|
||||
5.2.21 fue la última actualización estable del lanzamiento 5.2.
|
||||
|
||||
Algunos kernels se designan como kernels “a largo plazo”; recibirán
|
||||
soporte durante un periodo más largo. Consulte el siguiente enlace para
|
||||
obtener la lista de versiones activas del kernel a largo plazos y sus
|
||||
maintainers:
|
||||
|
||||
https://www.kernel.org/category/releases.html
|
||||
|
||||
La selección de un kernel para soporte a largo plazo es puramente una
|
||||
cuestión de que un maintainer tenga la necesidad y el tiempo para
|
||||
mantener ese lanzamiento. No hay planes conocidos para ofrecer soporte a
|
||||
largo plazo para ningún lanzamiento especifico próximo.
|
||||
|
||||
Ciclo de vida de un parche
|
||||
--------------------------
|
||||
|
||||
Los parches no van directamente desde el teclado del desarrollador al
|
||||
kernel mainline. Hay, en cambio, un proceso algo complicado (aunque algo
|
||||
informal) diseñado para garantizar que cada parche sea revisado en cuanto
|
||||
a calidad y que cada parche implemente un cambio que es deseable tener en
|
||||
el mainline. Este proceso puede ocurrir rápidamente para correcciones
|
||||
menores, o, en el caso de cambios grandes y controvertidos, continuar
|
||||
durante años. Gran parte de la frustración de los desarrolladores proviene
|
||||
de la falta de compresión de este proceso o de sus intentos de eludirlo.
|
||||
|
||||
Con la esperanza de reducir esa frustración, este documento describirá
|
||||
cómo un parche entra en el kernel. Lo que sigue a continuación es una
|
||||
introducción que describe el proceso de una manera tanto idealizada. Un
|
||||
tratamiento mucho más detallado vendrá en secciones posteriores.
|
||||
|
||||
Las etapas por las que pasa un parche son, generalmente:
|
||||
|
||||
- Diseño. Aquí es donde se establecen los requisitos reales para el
|
||||
parche – y la forma en que se cumplirán esos requisitos. El trabajo
|
||||
de diseño a menudo se realiza sin involucrar a la comunidad, pero es
|
||||
mejor hacer este trabajo de manera abierta si es posible; puede ahorrar
|
||||
mucho tiempo rediseñando las cosas más tarde.
|
||||
|
||||
- Revisión inicial. Los parches se publican en la lista de correo
|
||||
relevante y los desarrolladores en esa lista responden con cualquier
|
||||
comentario que puedan tener. Este proceso debería revelar cualquier
|
||||
problema importante con un parche si todo va bien.
|
||||
|
||||
- Revisión más amplia. Cuando el parche se acerca a estar listo para su
|
||||
inclusión en el mainline, debe ser aceptado por un maintainer del
|
||||
subsistema relevante – aunque esta aceptación no es una garantía de
|
||||
que el parche llegara hasta el mainline. El parche aparecerá en el
|
||||
árbol de subsistemas del maintainer y en los árboles -next (descritos
|
||||
a continuación). Cuando el proceso funciona, este paso conduce a una
|
||||
revisión exhaustiva del parche y al descubrimiento de cualquier
|
||||
problema resultante de la integración de este parche con el trabajo
|
||||
realizado por otros.
|
||||
|
||||
- Tenga en cuenta que la mayoría de los maintainers también tienen
|
||||
trabajos diurnos, por lo que fusionar su parche no puede ser su máxima
|
||||
prioridad. Si su parche está recibiendo comentarios sobre los cambios
|
||||
que se necesitan, debería realizar esos cambios o justificar por qué
|
||||
no deberían realizarse. Si su parche no tiene quejas de revisión, pero
|
||||
no está siendo fusionado por el maintainer apropiado del subsistema o
|
||||
del driver, debe ser persistente en la actualización del parche
|
||||
al kernel actual para que se aplique limpiamente y seguir enviándolo
|
||||
para su revisión y fusión.
|
||||
|
||||
- Fusión en el mainline. Eventualmente, un parche exitoso se fusionará
|
||||
en el repositorio mainline administrado por Linux Torvalds. Mas
|
||||
comentarios y/o problemas pueden surgir en este momento; es importante
|
||||
que el desarrollador responda a estos y solucione cualquier problema
|
||||
que surja.
|
||||
|
||||
- Lanzamiento estable. El número de usuarios potencialmente afectados por
|
||||
el parche es ahora grande, por lo que, una vez más, pueden surgir
|
||||
nuevos problemas.
|
||||
|
||||
- Mantenimiento a largo plazo. Si bien un desarrollador puede olvidarse
|
||||
del código después de fusionarlo, ese comportamiento tiende a dejar
|
||||
una impresión negativa en la comunidad de desarrollo. Fusionar el
|
||||
código elimina parte de la carga de mantenimiento; otros solucionarán
|
||||
los problemas causados por los cambios en la API. Sin embargo, el
|
||||
desarrollador original debe seguir asumiendo la responsabilidad del
|
||||
código si quiere seguir siendo útil a largo plazo.
|
||||
|
||||
Uno de los peores errores cometidos por los desarrolladores del kernel
|
||||
(o sus empleadores) es tratar de reducir el proceso a un solo paso de
|
||||
“fusión en el mainline”. Este enfoque conduce invariablemente a la
|
||||
frustración de todos los involucrados.
|
||||
|
||||
Cómo se integran los parches en el kernel
|
||||
-----------------------------------------
|
||||
|
||||
Hay exactamente una persona que puede fusionar parches en el repositorio
|
||||
mainline del kernel: Linus Torvalds. Pero, por ejemplo, de los más de
|
||||
9,500 parches que se incluyeron en el kernel 2.6.38, solo 112 (alrededor
|
||||
del 1.3%) fueron elegidos directamente por Linus mismo. El proyecto del
|
||||
kernel ha crecido mucho desde hace tiempo a un tamaño en el que ningún
|
||||
desarrollador individual podría inspeccionar y seleccionar todos los
|
||||
parches sin ayuda. La forma que los desarrolladores del kernel han
|
||||
abordado este crecimiento es a través del uso de un sistema jerárquico
|
||||
alrededor de una cadena de confianza.
|
||||
|
||||
La base de código del kernel se descompone lógicamente en un conjunto de
|
||||
subsistemas: redes, soporte de arquitectura especifica, gestión de
|
||||
memoria, dispositivos de video, etc. La mayoría de los subsistemas tienen
|
||||
un maintainer designado, un desarrollador que tiene la responsabilidad
|
||||
general del código dentro de ese subsistema. Estos maintainers de
|
||||
subsistemas son los guardianes (en cierto modo) de la parte del kernel que
|
||||
gestionan; son los que (usualmente) aceptarán un parche para incluirlo en
|
||||
el kernel mainline.
|
||||
|
||||
Cada uno de los maintainers del subsistema administra su propia versión
|
||||
del árbol de fuentes del kernel, generalmente (pero, ciertamente no
|
||||
siempre) usando la herramienta de administración de código fuente de git.
|
||||
Herramientas como git (y herramientas relacionadas como quilt o mercurial)
|
||||
permiten a los maintainers realizar un seguimiento de una lista de
|
||||
parches, incluida la información de autoría y otros metadatos. En
|
||||
cualquier momento, el maintainer puede identificar qué parches de su
|
||||
repositorio no se encuentran en el mainline.
|
||||
|
||||
Cuando se abre la ventana de fusión, los maintainers de nivel superior
|
||||
le pedirán a Linus que “extraiga” los parches que han seleccionado para
|
||||
fusionar de sus repositorios. Si Linus está de acuerdo, el flujo de
|
||||
parches fluirá hacia su repositorio, convirtiéndose en parte del kernel
|
||||
mainline. La cantidad de atención que Linus presta a los parches
|
||||
específicos recibidos en una operación de extracción varia. Está claro
|
||||
que, a veces, examina bastante de cerca. Pero, como regla general, Linus
|
||||
confía en que los maintainers del subsistema no envíen parches
|
||||
defectuosos al upstream.
|
||||
|
||||
Los maintainers de subsistemas, a su vez, pueden extraer parches de otros
|
||||
maintainers. Por ejemplo, el árbol de red se construye a partir de
|
||||
parches que se acumulan primero en arboles dedicados a drivers de
|
||||
dispositivos de red, redes inalámbricas, etc. Esta cadena de repositorios
|
||||
puede ser arbitrariamente larga, aunque rara vez supera los dos o tres
|
||||
enlaces. Dado que cada maintainer de la cadena confía en los que
|
||||
administran árboles de nivel inferior, este proceso se conoce como la
|
||||
“cadena de confianza”.
|
||||
|
||||
Claramente, en un sistema como este, lograr que los parches se integren
|
||||
en el kernel depende de encontrar el maintainer adecuado. Enviar parches
|
||||
directamente a Linus no es normalmente la forma correcta de hacerlo.
|
||||
|
||||
Árboles siguientes (next)
|
||||
-------------------------
|
||||
|
||||
La cadena de árboles de subsistemas guía el flujo de parches en el
|
||||
kernel, pero también plantea una pregunta interesante: ¿Qué pasa si
|
||||
alguien quiere ver todos los parches que se están preparando para la
|
||||
próxima ventana de fusión? Los desarrolladores estarán interesados en
|
||||
saber que otros cambios están pendientes para ver si hay algún conflicto
|
||||
del que preocuparse; un parche que cambia un prototipo de función del
|
||||
núcleo del kernel, por ejemplo, entrará en conflicto con cualquier otro
|
||||
parche que utilice la forma anterior de esa función. Los revisores y
|
||||
probadores quieren tener acceso a los cambios en su forma integrada antes
|
||||
de que todos esos cambios se integren en el kernel mainline. Uno podría
|
||||
extraer cambios de todos los árboles de subsistemas interesantes, pero
|
||||
eso sería un trabajo tedioso y propenso a errores.
|
||||
|
||||
La respuesta viene en forma de árboles -next, donde los árboles de
|
||||
subsistemas se recopilan para pruebas y revisiones. El más antiguo de
|
||||
estos árboles, mantenido por Andrew Morton, se llama “-mm” (por gestión
|
||||
de la memoria, que es como comenzó). El árbol “-mm” integra parches
|
||||
de una larga lista de árboles de subsistemas; también tiene algunos
|
||||
parches destinados a ayudar con la depuración.
|
||||
|
||||
Más allá de eso, -mm contiene una colección significativa de parches
|
||||
que han sido seleccionados directamente por Andrew. Estos parches pueden
|
||||
haber sido publicados en una lista de correo o aplicarse a una parte del
|
||||
kernel para la que no hay un árbol de subsistemas designado. Como
|
||||
resultado, -mm funciona como una especie de árbol de subsistemas de
|
||||
último recurso; si no hay otro camino obvio para un parche en el mainline,
|
||||
es probable que termine en -mm. Los parches misceláneos que se acumulan
|
||||
en -mm eventualmente se enviarán a un árbol de subsistema apropiado o se
|
||||
enviarán directamente a Linus. En un ciclo de desarrollo típico,
|
||||
aproximadamente el 5-10% de los parches que van al mainline llegan allí
|
||||
a través de -mm.
|
||||
|
||||
El parche -mm actual está disponible en el directorio “mmotm” (-mm
|
||||
del momento) en:
|
||||
|
||||
https://www.ozlabs.org/~akpm/mmotm/
|
||||
|
||||
Sin embargo, es probable que el uso del árbol MMOTM sea una experiencia
|
||||
frustrante; existe una posibilidad definitiva de que ni siquiera se
|
||||
compile.
|
||||
|
||||
El árbol principal para la fusión de parches del siguiente ciclo es
|
||||
linux-next, mantenido por Stephen Rothwell. El árbol linux-next es, por
|
||||
diseño, una instantánea de cómo se espera que se vea el mainline después
|
||||
de que se cierre la siguiente ventana de fusión. Los árboles linux-next
|
||||
se anuncian en las listas de correo linux-kernel y linux-next cuando se
|
||||
ensamblan; Se pueden descargar desde:
|
||||
|
||||
https://www.kernel.org/pub/linux/kernel/next/
|
||||
|
||||
Linux-next se ha convertido en una parte integral del proceso de
|
||||
desarrollo del kernel; todos los parches fusionados durante una ventana
|
||||
de fusión determinada deberían haber encontrado su camino en linux-next
|
||||
en algún momento antes de que se abra la ventana de fusión.
|
||||
|
||||
Árboles de staging
|
||||
------------------
|
||||
|
||||
El árbol de fuentes del kernel contiene el directorio drivers/staging/,
|
||||
donde residen muchos subdirectorios para drivers o sistemas de archivos
|
||||
que están en proceso de ser agregados al árbol del kernel. Permanecen
|
||||
en drivers/staging mientras aún necesitan más trabajo; una vez
|
||||
completados, se pueden mover al kernel propiamente dicho. Esta es una
|
||||
forma de realizar un seguimiento de los drivers drivers que no están a la
|
||||
altura de la codificación o los estándares de calidad del kernel de
|
||||
Linux, pero que las personas pueden querer usarlos y realizar un
|
||||
seguimiento del desarrollo.
|
||||
|
||||
Greg Kroah-Hartman mantiene actualmente el árbol de staging. Los drivers
|
||||
que aun necesitan trabajo se le envían, y cada driver tiene su propio
|
||||
subdirectorio en drivers/staging/. Junto con los archivos de origen del
|
||||
driver, también debe haber un archivo TODO en el directorio. El archivo
|
||||
TODO enumera el trabajo pendiente que el driver necesita para ser aceptado
|
||||
en el kernel propiamente dicho, así como una lista de personas a las que
|
||||
Cc’d para cualquier parche para el driver. Las reglas actuales exigen
|
||||
que los drivers que contribuyen a staging deben, como mínimo, compilarse
|
||||
correctamente.
|
||||
|
||||
El staging puede ser una forma relativamente fácil de conseguir nuevos
|
||||
drivers en el mainline donde, con suerte, llamarán la atención de otros
|
||||
desarrolladores y mejorarán rápidamente. Sin embargo, la entrada en el
|
||||
staging no es el final de la historia; el código que no está viendo
|
||||
progreso regular eventualmente será eliminado. Los distribuidores también
|
||||
tienden a ser relativamente reacios a habilitar los drivers de staging.
|
||||
Por lo tanto, el staging es, en el mejor de los casos, una parada en el
|
||||
camino para hacia convertirse en un apropiado driver del mainline.
|
||||
|
||||
Herramientas
|
||||
------------
|
||||
|
||||
Como se puede ver en el texto anterior, el proceso de desarrollo del
|
||||
kernel depende en gran medida de la capacidad de dirigir colecciones de
|
||||
parches en varias direcciones. Todo ello no funcionaría tan bien como lo
|
||||
hace sin herramientas apropiadamente potentes. Los tutoriales sobre cómo
|
||||
usar estas herramientas están mucho más allá del alcance de este
|
||||
documento, pero hay espacio para algunos consejos.
|
||||
|
||||
Con mucho, el sistema de gestión de código fuente dominante utilizado
|
||||
por la comunidad del kernel es git. Git es uno de los varios sistemas de
|
||||
control de versiones distribuidos que se están desarrollando en la
|
||||
comunidad de software libre. Está bien ajustado para el desarrollo de
|
||||
kernel, ya que funciona bastante bien cuando se trata de grandes
|
||||
repositorios y grandes cantidades de parches. También tiene la reputación
|
||||
de ser difícil de aprender y usar, aunque ha mejorado con el tiempo.
|
||||
Algún tipo de familiaridad con git es casi un requisito para los
|
||||
desarrolladores del kernel; incluso si no lo usan para su propio
|
||||
trabajo, necesitarán git para mantenerse al día con lo que otros
|
||||
desarrolladores (y el mainline) están haciendo.
|
||||
|
||||
Git ahora está empaquetado por casi todas las distribuciones de Linux.
|
||||
Hay una página de inicio en:
|
||||
|
||||
https://git-scm.com/
|
||||
|
||||
Esa página tiene punteros a documentación y tutoriales.
|
||||
|
||||
Entre los desarrolladores de kernel que no usan git, la opción más
|
||||
popular es casi con certeza Mercurial:
|
||||
|
||||
https://www.selenic.com/mercurial/
|
||||
|
||||
Mercurial comparte muchas características con git, pero proporciona una
|
||||
interfaz que muchos encuentran más fácil de usar.
|
||||
|
||||
Otra herramienta que vale la pena conocer es Quilt:
|
||||
|
||||
https://savannah.nongnu.org/projects/quilt/
|
||||
|
||||
Quilt es un sistema de gestión de parches, en lugar de un sistema de
|
||||
gestión de código fuente. No rastrea el historial a lo largo del tiempo;
|
||||
en cambio, está orientado al seguimiento de un conjunto especifico de
|
||||
cambios en relación con una base de código en evolución. Algunos de los
|
||||
principales maintainers de subsistemas utilizan Quilt para gestionar los
|
||||
parches destinados a ir upstream. Para la gestión de ciertos tipos de
|
||||
árboles (por ejemplo, -mm) Quilt es la mejor herramienta para el trabajo.
|
||||
|
||||
Listas de correo
|
||||
----------------
|
||||
|
||||
Una gran parte del trabajo de desarrollo del kernel de Linux se realiza a
|
||||
través de listas de correo. Es difícil ser un miembro plenamente funcional
|
||||
de la comunidad sin unirse al menos a una lista en algún parte. Pero las
|
||||
listas de correo de Linux también representan un peligro potencial para
|
||||
los desarrolladores, que corren el riesgo de quedar enterrados bajo una
|
||||
carga de correo electrónico, incumplir las convenciones utilizadas en las
|
||||
listas de Linux, o ambas cosas.
|
||||
|
||||
La mayoría de las listas de correo del kernel se ejecutan en
|
||||
vger.kernel.org; la lista principal se puede encontrar en:
|
||||
|
||||
http://vger.kernel.org/vger-lists.html
|
||||
|
||||
Sim embargo, hay listas alojadas en otros lugares; varios de ellos se
|
||||
encuentran en redhat.com/mailman/listinfo.
|
||||
|
||||
La lista de correo principal para el desarrollo del kernel es, por
|
||||
supuesto, linux-kernel. Esta lista es un lugar intimidante; el volumen
|
||||
puede alcanzar 500 mensajes por día, la cantidad de ruido es alta, la
|
||||
conversación puede ser muy técnica y los participantes no siempre se
|
||||
preocupan por mostrar un alto grado de cortesía. Pero no hay otro lugar
|
||||
donde la comunidad de desarrollo del kernel se reúna como un todo; los
|
||||
desarrolladores que eviten esta lista se perderán información importante.
|
||||
|
||||
Hay algunos consejos que pueden ayudar a sobrevivir en el kernel de Linux:
|
||||
|
||||
- Haga que la lista se entregue en una carpeta separada, en lugar de su
|
||||
buzón principal. Uno debe ser capaz de ignorar el flujo durante
|
||||
periodos prolongados.
|
||||
|
||||
- No trate de seguir cada conversación, nadie lo hace. Es importante
|
||||
filtrar tanto por el tema de interés (aunque tenga en cuenta que las
|
||||
conversaciones prolongadas pueden alejarse del asunto original sin
|
||||
cambiar la línea de asunto del correo electrónico) por las personas
|
||||
que participan.
|
||||
|
||||
- No alimente a los trolls. Si alguien está tratando de provocar una
|
||||
respuesta de enojo, ignórelos.
|
||||
|
||||
- Al responder al correo electrónico del kernel de Linux (o al de otras
|
||||
listas) conserve el encabezado Cc: para todos los involucrados. En
|
||||
ausencia de una razón solida (como una solicitud explícita), nunca debe
|
||||
eliminar destinarios. Asegúrese siempre de que la persona a la que está
|
||||
respondiendo esté en la lista Cc:. Esta convención también hace que no
|
||||
sea necesario solicitar explícitamente que se le copie en las respuestas
|
||||
a sus publicaciones.
|
||||
|
||||
- Busque en los archivos de la lista (y en la red en su conjunto) antes
|
||||
de hacer preguntas. Algunos desarrolladores pueden impacientarse con
|
||||
las personas que claramente no han hecho sus deberes.
|
||||
|
||||
- Utilice respuestas intercaladas (“en línea”), lo que hace que su
|
||||
respuesta sea más fácil de leer. (Es decir, evite top-posting – la
|
||||
práctica de poner su respuesta encima del texto citado al que está
|
||||
respondiendo.) Para obtener más información, consulte
|
||||
:ref:`Documentation/translations/sp_SP/process/submitting-patches.rst <sp_interleaved_replies>`.
|
||||
|
||||
- Pregunte en la lista de correo correcta. linux-kernel puede ser el
|
||||
punto de encuentro general, pero no es el mejor lugar para encontrar
|
||||
desarrolladores de todos los subsistemas.
|
||||
|
||||
El último punto, encontrar la lista de correo correcta, es una fuente
|
||||
común de errores para desarrolladores principiantes. Alguien que haga
|
||||
una pregunta relacionada con las redes en linux-kernel seguramente
|
||||
recibirá una surgencia educada para preguntar en la lista de netdev en su
|
||||
lugar, ya que esa es la lista frecuentada por la mayoría de los
|
||||
desarrolladores de redes. Existen otras listas para los subsistemas SCSI,
|
||||
video4linux, IDE, sistema de archivos, etc. El mejor lugar para buscar
|
||||
listas de correo es en el archivo MAINTAINERS incluido con el código
|
||||
fuente del kernel.
|
||||
|
||||
Comenzar con el desarrollo del kernel
|
||||
-------------------------------------
|
||||
|
||||
Las preguntas sobre como comenzar con el proceso de desarrollo del kernel
|
||||
son comunes, tanto de individuos como de empresas. Igualmente comunes son
|
||||
los pasos en falso que hacen que el comienzo de la relación sea más
|
||||
difícil de lo que tiene que ser.
|
||||
|
||||
Las empresas a menudo buscan contratar desarrolladores conocidos para
|
||||
iniciar un grupo de desarrollo. De hecho, esta puede ser una técnica
|
||||
efectiva. Pero también tiende a ser caro y no hace mucho para crecer el
|
||||
grupo de desarrolladores de kernel experimentados. Es posible poner al
|
||||
día a los desarrolladores internos en el desarrollo de kernel de Linux,
|
||||
dada la inversión de algún tiempo. Tomarse este tiempo puede dotar a un
|
||||
empleador de un grupo de desarrolladores que comprendan tanto el kernel
|
||||
como la empresa, y que también puedan ayudar a educar a otros. A medio
|
||||
plazo, este es a menudo el enfoque más rentable.
|
||||
|
||||
Los desarrolladores individuales, a menudo, comprensiblemente, no tienen
|
||||
un lugar para empezar. Comenzar con un proyecto grande puede ser
|
||||
intimidante; a menudo uno quiere probar las aguas con algo más pequeño
|
||||
primero. Este es el punto en el que algunos desarrolladores se lanzan a
|
||||
la creación de parches para corregir errores ortográficos o problemas
|
||||
menores de estilo de codificación. Desafortunadamente, dicho parches
|
||||
crean un nivel de ruido que distrae a la comunidad de desarrollo en su
|
||||
conjunto, por lo que, cada vez más, se los mira con desprecio. Los nuevos
|
||||
desarrolladores que deseen presentarse a la comunidad no recibirán la
|
||||
recepción que desean por estos medios.
|
||||
|
||||
Andrew Morton da este consejo (traducido) para los aspirantes a
|
||||
desarrolladores de kernel.
|
||||
|
||||
::
|
||||
|
||||
El proyecto #1 para los principiantes en el kernel seguramente debería
|
||||
ser “asegúrese de que el kernel funcione perfectamente en todo momento
|
||||
en todas las máquinas que pueda conseguir”. Por lo general, la forma
|
||||
de hacer esto es trabajar con otros para arreglar las cosas (¡esto
|
||||
puede requerir persistencia!), pero eso está bien, es parte del
|
||||
desarrollo del kernel.
|
||||
|
||||
(https://lwn.net/Articles/283982/)
|
||||
|
||||
En ausencia de problemas obvios que solucionar, se aconseja a los
|
||||
desarrolladores que consulten las listas actuales de regresiones y errores
|
||||
abiertos en general. Nunca faltan problemas que necesitan solución; al
|
||||
abordar estos problemas, los desarrolladores ganarán experiencia con el
|
||||
proceso mientras, al mismo tiempo, se ganarán el respeto del resto de la
|
||||
comunidad de desarrollo.
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/3.Early-stage.rst
|
||||
|
||||
.. _sp_development_early_stage:
|
||||
|
||||
Planificación en etapa inicial
|
||||
==============================
|
||||
|
||||
.. warning::
|
||||
TODO aún no traducido
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/4.Coding.rst
|
||||
|
||||
.. _sp_development_coding:
|
||||
|
||||
Conseguir el código correcto
|
||||
============================
|
||||
|
||||
.. warning::
|
||||
TODO aún no traducido
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/5.Posting.rst
|
||||
|
||||
.. _sp_development_posting:
|
||||
|
||||
Publicar parches
|
||||
================
|
||||
|
||||
.. warning::
|
||||
TODO aún no traducido
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/6.Followthrough.rst
|
||||
|
||||
.. _sp_development_followthrough:
|
||||
|
||||
Seguimiento
|
||||
===========
|
||||
|
||||
.. warning::
|
||||
TODO aún no traducido
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/7.AdvancedTopics.rst
|
||||
|
||||
.. _sp_development_advancedtopics:
|
||||
|
||||
Temas avanzados
|
||||
===============
|
||||
|
||||
.. warning::
|
||||
TODO aún no traducido
|
||||
|
|
@ -0,0 +1,11 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/8.Conclusion.rst
|
||||
|
||||
.. _sp_development_conclusion:
|
||||
|
||||
Para más información
|
||||
====================
|
||||
|
||||
.. warning::
|
||||
TODO aún no traducido
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/code-of-conduct.rst <code_of_conduct>`
|
||||
:Translator: Contributor Covenant and Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Contributor Covenant and Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_code_of_conduct:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/coding-style.rst <submittingpatches>`
|
||||
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_codingstyle:
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,27 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: Documentation/process/development-process.rst
|
||||
:Translator: Avadhut Naik <avadhut.naik@amd.com>
|
||||
|
||||
.. _sp_development_process_main:
|
||||
|
||||
Guía del proceso de desarrollo del kernel
|
||||
=========================================
|
||||
|
||||
El propósito de este documento es ayudar a los desarrolladores (y sus
|
||||
gerentes) a trabajar con la comunidad de desarrollo con un mínimo de
|
||||
frustración. Es un intento de documentar cómo funciona esta comunidad
|
||||
de una manera accesible para aquellos que no están familiarizados
|
||||
íntimamente con el desarrollo del kernel de Linux (o, de hecho, el
|
||||
desarrollo de software libre en general). Si bien hay algo de material
|
||||
técnico aquí, este es en gran medida una discusión orientada al proceso
|
||||
que no requiere un conocimiento profundo de la programación del kernel
|
||||
para entenderla.
|
||||
|
||||
.. toctree::
|
||||
:caption: Contenido
|
||||
:numbered:
|
||||
:maxdepth: 2
|
||||
|
||||
1.Intro
|
||||
2.Process
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/email-clients.rst <email_clients>`
|
||||
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_email_clients:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/howto.rst <process_howto>`
|
||||
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_process_howto:
|
||||
|
||||
|
|
|
|||
|
|
@ -28,3 +28,4 @@
|
|||
management-style
|
||||
submit-checklist
|
||||
howto
|
||||
development-process
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/kernel-docs.rst <kernel_docs>`
|
||||
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_kernel_docs:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/kernel-enforcement-statement.rst <process_statement_kernel>`
|
||||
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_process_statement_kernel:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
|
||||
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_magicnumbers:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/programming-language.rst <programming_language>`
|
||||
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_programming_language:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
.. include:: ../disclaimer-sp.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
:Translator: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
|
||||
.. _sp_submittingpatches:
|
||||
|
||||
|
|
@ -356,6 +356,34 @@ Consulte Documentation/process/email-clients.rst para obtener
|
|||
recomendaciones sobre clientes de correo electrónico y normas de etiqueta
|
||||
en la lista de correo.
|
||||
|
||||
.. _sp_interleaved_replies:
|
||||
|
||||
Uso de respuestas intercaladas recortadas en las discusiones por correo electrónico
|
||||
-----------------------------------------------------------------------------------
|
||||
|
||||
Se desaconseja encarecidamente la publicación en la parte superior de las
|
||||
discusiones sobre el desarrollo del kernel de Linux. Las respuestas
|
||||
intercaladas (o "en línea") hacen que las conversaciones sean mucho más
|
||||
fáciles de seguir. Para obtener más detalles, consulte:
|
||||
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
|
||||
|
||||
Como se cita frecuentemente en la lista de correo::
|
||||
|
||||
A: http://en.wikipedia.org/wiki/Top_post
|
||||
Q: ¿Dónde puedo encontrar información sobre esto que se llama top-posting?
|
||||
A: Porque desordena el orden en el que la gente normalmente lee el texto.
|
||||
Q: ¿Por qué es tan malo el top-posting?
|
||||
A: Top-posting.
|
||||
Q: ¿Qué es lo más molesto del correo electrónico?
|
||||
|
||||
Del mismo modo, por favor, recorte todas las citas innecesarias que no
|
||||
sean relevantes para su respuesta. Esto hace que las respuestas sean más
|
||||
fáciles de encontrar y ahorra tiempo y espacio. Para obtener más
|
||||
información, consulte: http://daringfireball.net/2007/07/on_top ::
|
||||
|
||||
A: No.
|
||||
Q: ¿Debo incluir citas después de mi respuesta?
|
||||
|
||||
.. _sp_resend_reminders:
|
||||
|
||||
No se desanime o impaciente
|
||||
|
|
|
|||
|
|
@ -22,14 +22,14 @@ Documentation/translations/zh_CN/dev-tools/testing-overview.rst
|
|||
sparse
|
||||
gcov
|
||||
kasan
|
||||
kcov
|
||||
ubsan
|
||||
kmemleak
|
||||
gdb-kernel-debugging
|
||||
|
||||
Todolist:
|
||||
|
||||
- coccinelle
|
||||
- kcov
|
||||
- ubsan
|
||||
- kmemleak
|
||||
- kcsan
|
||||
- kfence
|
||||
- kgdb
|
||||
|
|
|
|||
|
|
@ -0,0 +1,359 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/dev-tools/kcov.rst
|
||||
:Translator: 刘浩阳 Haoyang Liu <tttturtleruss@hust.edu.cn>
|
||||
|
||||
KCOV: 用于模糊测试的代码覆盖率
|
||||
==============================
|
||||
|
||||
KCOV 以一种适用于覆盖率引导的模糊测试的形式收集和暴露内核代码覆盖率信息。
|
||||
一个正在运行的内核的覆盖率数据可以通过 ``kcov`` 调试文件导出。覆盖率的收集是基
|
||||
于任务启用的，因此 KCOV 可以精确捕获单个系统调用的覆盖率。
|
||||
|
||||
要注意的是 KCOV 不是为了收集尽可能多的覆盖率数据。而是为了收集相对稳定的覆盖率
|
||||
，这是系统调用输入的函数。为了完成这个目标，它不收集软硬中断的覆盖率（除非移除
|
||||
覆盖率收集被启用，见下文）以及内核中固有的不确定部分的覆盖率（如调度器，锁定）
|
||||
|
||||
除了收集代码覆盖率，KCOV 还收集操作数比较的覆盖率。见 "操作数比较收集" 一节
|
||||
查看详细信息。
|
||||
|
||||
除了从系统调用处理器收集覆盖率数据，KCOV 还从后台内核或软中断任务中执行的内核
|
||||
被标注的部分收集覆盖率。见 "远程覆盖率收集" 一节查看详细信息。
|
||||
|
||||
先决条件
|
||||
--------
|
||||
|
||||
KCOV 依赖编译器插桩，要求 GCC 6.1.0 及更高版本或者内核支持的任意版本的 Clang。
|
||||
|
||||
收集操作数比较的覆盖率需要 GCC 8+ 或者 Clang。
|
||||
|
||||
为了启用 KCOV，需要使用如下参数配置内核::
|
||||
|
||||
CONFIG_KCOV=y
|
||||
|
||||
为了启用操作数比较覆盖率的收集，使用如下参数::
|
||||
|
||||
CONFIG_KCOV_ENABLE_COMPARISONS=y
|
||||
|
||||
覆盖率数据只会在调试文件系统被挂载后才可以获取::
|
||||
|
||||
mount -t debugfs none /sys/kernel/debug
|
||||
|
||||
覆盖率收集
|
||||
----------
|
||||
|
||||
下面的程序演示了如何使用 KCOV 在一个测试程序中收集单个系统调用的覆盖率：
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
#include <stdio.h>
|
||||
#include <stddef.h>
|
||||
#include <stdint.h>
|
||||
#include <stdlib.h>
|
||||
#include <sys/types.h>
|
||||
#include <sys/stat.h>
|
||||
#include <sys/ioctl.h>
|
||||
#include <sys/mman.h>
|
||||
#include <unistd.h>
|
||||
#include <fcntl.h>
|
||||
#include <linux/types.h>
|
||||
|
||||
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
|
||||
#define KCOV_ENABLE _IO('c', 100)
|
||||
#define KCOV_DISABLE _IO('c', 101)
|
||||
#define COVER_SIZE (64<<10)
|
||||
|
||||
#define KCOV_TRACE_PC 0
|
||||
#define KCOV_TRACE_CMP 1
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
int fd;
|
||||
unsigned long *cover, n, i;
|
||||
|
||||
/* 单个文件描述符允许
|
||||
* 在单线程上收集覆盖率。
|
||||
*/
|
||||
fd = open("/sys/kernel/debug/kcov", O_RDWR);
|
||||
if (fd == -1)
|
||||
perror("open"), exit(1);
|
||||
/* 设置跟踪模式和跟踪大小。 */
|
||||
if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE))
|
||||
perror("ioctl"), exit(1);
|
||||
/* 映射内核空间和用户空间共享的缓冲区。 */
|
||||
cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long),
|
||||
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
|
||||
if ((void*)cover == MAP_FAILED)
|
||||
perror("mmap"), exit(1);
|
||||
/* 在当前线程中启用覆盖率收集。 */
|
||||
if (ioctl(fd, KCOV_ENABLE, KCOV_TRACE_PC))
|
||||
perror("ioctl"), exit(1);
|
||||
/* 在调用 ioctl() 之后重置覆盖率。 */
|
||||
__atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED);
|
||||
/* 调用目标系统调用。 */
|
||||
read(-1, NULL, 0);
|
||||
/* 读取收集到的 PC 的数目。 */
|
||||
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
|
||||
for (i = 0; i < n; i++)
|
||||
printf("0x%lx\n", cover[i + 1]);
|
||||
/* 在当前线程上禁用覆盖率收集。在这之后
|
||||
* 可以在其他线程上收集覆盖率
|
||||
*/
|
||||
if (ioctl(fd, KCOV_DISABLE, 0))
|
||||
perror("ioctl"), exit(1);
|
||||
/* 释放资源 */
|
||||
if (munmap(cover, COVER_SIZE * sizeof(unsigned long)))
|
||||
perror("munmap"), exit(1);
|
||||
if (close(fd))
|
||||
perror("close"), exit(1);
|
||||
return 0;
|
||||
}
|
||||
|
||||
在使用 ``addr2line`` 传输后，程序输出应该如下所示::
|
||||
|
||||
SyS_read
|
||||
fs/read_write.c:562
|
||||
__fdget_pos
|
||||
fs/file.c:774
|
||||
__fget_light
|
||||
fs/file.c:746
|
||||
__fget_light
|
||||
fs/file.c:750
|
||||
__fget_light
|
||||
fs/file.c:760
|
||||
__fdget_pos
|
||||
fs/file.c:784
|
||||
SyS_read
|
||||
fs/read_write.c:562
|
||||
|
||||
如果一个程序需要从多个线程收集覆盖率（独立地）。那么每个线程都需要单独打开
|
||||
``/sys/kernel/debug/kcov``。
|
||||
|
||||
接口的细粒度允许高效的创建测试进程。即，一个父进程打开了
|
||||
``/sys/kernel/debug/kcov``，启用了追踪模式，映射了覆盖率缓冲区，然后在一个循
|
||||
环中创建了子进程。这个子进程只需要启用覆盖率收集即可（当一个线程退出时将自动禁
|
||||
用覆盖率收集）。
|
||||
|
||||
操作数比较收集
|
||||
--------------
|
||||
|
||||
操作数比较收集和覆盖率收集类似：
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* 包含和上文一样的头文件和宏定义。 */
|
||||
|
||||
/* 每次记录的 64 位字的数量。 */
|
||||
#define KCOV_WORDS_PER_CMP 4
|
||||
|
||||
/*
|
||||
* 收集的比较种类的格式。
|
||||
*
|
||||
* 0 比特表示是否是一个编译时常量。
|
||||
* 1 & 2 比特包含参数大小的 log2 值，最大 8 字节。
|
||||
*/
|
||||
|
||||
#define KCOV_CMP_CONST (1 << 0)
|
||||
#define KCOV_CMP_SIZE(n) ((n) << 1)
|
||||
#define KCOV_CMP_MASK KCOV_CMP_SIZE(3)
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
int fd;
|
||||
uint64_t *cover, type, arg1, arg2, is_const, size;
|
||||
unsigned long n, i;
|
||||
|
||||
fd = open("/sys/kernel/debug/kcov", O_RDWR);
|
||||
if (fd == -1)
|
||||
perror("open"), exit(1);
|
||||
if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE))
|
||||
perror("ioctl"), exit(1);
|
||||
/*
|
||||
* 注意缓冲区指针的类型是 uint64_t*，因为所有的
|
||||
* 比较操作数都被提升为 uint64_t 类型。
|
||||
*/
|
||||
cover = (uint64_t *)mmap(NULL, COVER_SIZE * sizeof(unsigned long),
|
||||
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
|
||||
if ((void*)cover == MAP_FAILED)
|
||||
perror("mmap"), exit(1);
|
||||
/* 注意这里是 KCOV_TRACE_CMP 而不是 KCOV_TRACE_PC。 */
|
||||
if (ioctl(fd, KCOV_ENABLE, KCOV_TRACE_CMP))
|
||||
perror("ioctl"), exit(1);
|
||||
__atomic_store_n(&cover[0], 0, __ATOMIC_RELAXED);
|
||||
read(-1, NULL, 0);
|
||||
/* 读取收集到的比较操作数的数量。 */
|
||||
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
|
||||
for (i = 0; i < n; i++) {
|
||||
uint64_t ip;
|
||||
|
||||
type = cover[i * KCOV_WORDS_PER_CMP + 1];
|
||||
/* arg1 和 arg2 - 比较的两个操作数。 */
|
||||
arg1 = cover[i * KCOV_WORDS_PER_CMP + 2];
|
||||
arg2 = cover[i * KCOV_WORDS_PER_CMP + 3];
|
||||
/* ip - 调用者的地址。 */
|
||||
ip = cover[i * KCOV_WORDS_PER_CMP + 4];
|
||||
/* 操作数的大小。 */
|
||||
size = 1 << ((type & KCOV_CMP_MASK) >> 1);
|
||||
/* is_const - 当操作数是一个编译时常量时为真。*/
|
||||
is_const = type & KCOV_CMP_CONST;
|
||||
printf("ip: 0x%lx type: 0x%lx, arg1: 0x%lx, arg2: 0x%lx, "
|
||||
"size: %lu, %s\n",
|
||||
ip, type, arg1, arg2, size,
|
||||
is_const ? "const" : "non-const");
|
||||
}
|
||||
if (ioctl(fd, KCOV_DISABLE, 0))
|
||||
perror("ioctl"), exit(1);
|
||||
/* 释放资源。 */
|
||||
if (munmap(cover, COVER_SIZE * sizeof(unsigned long)))
|
||||
perror("munmap"), exit(1);
|
||||
if (close(fd))
|
||||
perror("close"), exit(1);
|
||||
return 0;
|
||||
}
|
||||
|
||||
注意 KCOV 的模式（代码覆盖率收集或操作数比较收集）是互斥的。
|
||||
|
||||
远程覆盖率收集
|
||||
--------------
|
||||
|
||||
除了从用户空间进程发布的系统调用句柄收集覆盖率数据以外，KCOV 也可以从部分在其
|
||||
他上下文中执行的内核中收集覆盖率 - 称为“远程”覆盖率。
|
||||
|
||||
使用 KCOV 收集远程覆盖率要求：
|
||||
|
||||
1. 修改内核源码并使用 ``kcov_remote_start`` 和 ``kcov_remote_stop`` 来标注要收集
|
||||
覆盖率的代码片段。
|
||||
|
||||
2. 在用户空间的收集覆盖率的进程应使用 ``KCOV_REMOTE_ENABLE`` 而不是 ``KCOV_ENABLE``。
|
||||
|
||||
``kcov_remote_start`` 和 ``kcov_remote_stop`` 的标注以及 ``KCOV_REMOTE_ENABLE``
|
||||
ioctl 都接受可以识别特定覆盖率收集片段的句柄。句柄的使用方式取决于匹配代码片段执
|
||||
行的上下文。
|
||||
|
||||
KCOV 支持在如下上下文中收集远程覆盖率：
|
||||
|
||||
1. 全局内核后台任务。这些任务是内核启动时创建的数量有限的实例（如，每一个
|
||||
USB HCD 产生一个 USB ``hub_event`` 工作器）。
|
||||
|
||||
2. 局部内核后台任务。这些任务通常是由于用户空间进程与某些内核接口进行交互时产
|
||||
生的，并且通常在进程退出时会被停止（如，vhost 工作器）。
|
||||
|
||||
3. 软中断。
|
||||
|
||||
对于 #1 和 #3，必须选择一个独特的全局句柄并将其传递给对应的
|
||||
``kcov_remote_start`` 调用。一个用户空间进程必须将该句柄存储在
|
||||
``kcov_remote_arg`` 结构体的 ``handle`` 数组字段中并将其传递给
|
||||
``KCOV_REMOTE_ENABLE``。这会将使用的 KCOV 设备附加到由此句柄引用的代码片段。多个全局
|
||||
句柄标识的不同代码片段可以一次性传递。
|
||||
|
||||
对于 #2，用户空间进程必须通过 ``kcov_remote_arg`` 结构体的 ``common_handle`` 字段
|
||||
传递一个非零句柄。这个通用句柄将会被保存在当前 ``task_struct`` 结构体的
|
||||
``kcov_handle`` 字段中并且需要通过自定义内核代码的修改来传递给新创建的本地任务
|
||||
。这些任务需要在 ``kcov_remote_start`` 和 ``kcov_remote_stop`` 标注中依次使用传递过来的
|
||||
句柄。
|
||||
|
||||
KCOV 对全局句柄和通用句柄均遵循一个预定义的格式。每一个句柄都是一个 ``u64`` 整形
|
||||
。当前，只有最高位和低四位字节被使用。第 4-7 字节是保留位并且值必须为 0。
|
||||
|
||||
对于全局句柄，最高位的字节表示该句柄属于的子系统的标识。比如，KCOV 使用 ``1``
|
||||
表示 USB 子系统类型。全局句柄的低 4 字节表示子系统中任务实例的标识。比如，每一
|
||||
个 ``hub_event`` 工作器使用 USB 总线号作为任务实例的标识。
|
||||
|
||||
对于通用句柄，使用一个保留值 ``0`` 作为子系统标识，因为这些句柄不属于一个特定
|
||||
的子系统。通用句柄的低 4 字节用于识别有用户进程生成的所有本地句柄的集合实例，
|
||||
该进程将通用句柄传递给 ``KCOV_REMOTE_ENABLE``。
|
||||
|
||||
实际上，如果只从系统中的单个用户空间进程收集覆盖率，那么可以使用任意值作为通用
|
||||
句柄的实例标识。然而，如果通用句柄被多个用户空间进程使用，每个进程必须使用唯一
|
||||
的实例标识。一个选择是使用进程标识作为通用句柄实例的标识。
|
||||
|
||||
下面的程序演示了如何使用 KCOV 从一个由进程产生的本地任务和处理 USB 总线的全局
|
||||
任务 #1 收集覆盖率：
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
/* 包含和上文一样的头文件和宏定义。 */
|
||||
|
||||
struct kcov_remote_arg {
|
||||
__u32 trace_mode;
|
||||
__u32 area_size;
|
||||
__u32 num_handles;
|
||||
__aligned_u64 common_handle;
|
||||
__aligned_u64 handles[0];
|
||||
};
|
||||
|
||||
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
|
||||
#define KCOV_DISABLE _IO('c', 101)
|
||||
#define KCOV_REMOTE_ENABLE _IOW('c', 102, struct kcov_remote_arg)
|
||||
|
||||
#define COVER_SIZE (64 << 10)
|
||||
|
||||
#define KCOV_TRACE_PC 0
|
||||
|
||||
#define KCOV_SUBSYSTEM_COMMON (0x00ull << 56)
|
||||
#define KCOV_SUBSYSTEM_USB (0x01ull << 56)
|
||||
|
||||
#define KCOV_SUBSYSTEM_MASK (0xffull << 56)
|
||||
#define KCOV_INSTANCE_MASK (0xffffffffull)
|
||||
|
||||
static inline __u64 kcov_remote_handle(__u64 subsys, __u64 inst)
|
||||
{
|
||||
if (subsys & ~KCOV_SUBSYSTEM_MASK || inst & ~KCOV_INSTANCE_MASK)
|
||||
return 0;
|
||||
return subsys | inst;
|
||||
}
|
||||
|
||||
#define KCOV_COMMON_ID 0x42
|
||||
#define KCOV_USB_BUS_NUM 1
|
||||
|
||||
int main(int argc, char **argv)
|
||||
{
|
||||
int fd;
|
||||
unsigned long *cover, n, i;
|
||||
struct kcov_remote_arg *arg;
|
||||
|
||||
fd = open("/sys/kernel/debug/kcov", O_RDWR);
|
||||
if (fd == -1)
|
||||
perror("open"), exit(1);
|
||||
if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE))
|
||||
perror("ioctl"), exit(1);
|
||||
cover = (unsigned long*)mmap(NULL, COVER_SIZE * sizeof(unsigned long),
|
||||
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
|
||||
if ((void*)cover == MAP_FAILED)
|
||||
perror("mmap"), exit(1);
|
||||
|
||||
/* 通过通用句柄和 USB 总线 #1 启用代码覆盖率收集。 */
|
||||
arg = calloc(1, sizeof(*arg) + sizeof(uint64_t));
|
||||
if (!arg)
|
||||
perror("calloc"), exit(1);
|
||||
arg->trace_mode = KCOV_TRACE_PC;
|
||||
arg->area_size = COVER_SIZE;
|
||||
arg->num_handles = 1;
|
||||
arg->common_handle = kcov_remote_handle(KCOV_SUBSYSTEM_COMMON,
|
||||
KCOV_COMMON_ID);
|
||||
arg->handles[0] = kcov_remote_handle(KCOV_SUBSYSTEM_USB,
|
||||
KCOV_USB_BUS_NUM);
|
||||
if (ioctl(fd, KCOV_REMOTE_ENABLE, arg))
|
||||
perror("ioctl"), free(arg), exit(1);
|
||||
free(arg);
|
||||
|
||||
/*
|
||||
* 在这里用户需要触发执行一个内核代码段
|
||||
* 该代码段要么使用通用句柄标识
|
||||
* 要么触发了一些 USB 总线 #1 上的一些活动。
|
||||
*/
|
||||
sleep(2);
|
||||
|
||||
n = __atomic_load_n(&cover[0], __ATOMIC_RELAXED);
|
||||
for (i = 0; i < n; i++)
|
||||
printf("0x%lx\n", cover[i + 1]);
|
||||
if (ioctl(fd, KCOV_DISABLE, 0))
|
||||
perror("ioctl"), exit(1);
|
||||
if (munmap(cover, COVER_SIZE * sizeof(unsigned long)))
|
||||
perror("munmap"), exit(1);
|
||||
if (close(fd))
|
||||
perror("close"), exit(1);
|
||||
return 0;
|
||||
}
|
||||
|
|
@ -0,0 +1,229 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/dev-tools/kmemleak.rst
|
||||
:Translator: 刘浩阳 Haoyang Liu <tttturtleruss@hust.edu.cn>
|
||||
|
||||
内核内存泄露检测器
|
||||
==================
|
||||
|
||||
Kmemleak 提供了一个类似 `可追踪的垃圾收集器 <https://en.wikipedia.org/wiki/Tra
|
||||
cing_garbage_collection>`_ 的方法来检测可能的内核内存泄漏，不同的是孤立对象不会
|
||||
被释放，而是仅通过 /sys/kernel/debug/kmemleak 报告。Valgrind 工具
|
||||
（``memcheck --leak-check``）使用了一种相似的方法来检测用户空间应用中的内存泄
|
||||
露。
|
||||
|
||||
用法
|
||||
----
|
||||
|
||||
"Kernel hacking" 中的 CONFIG_DEBUG_KMEMLEAK 必须被启用。一个内核线程每10分钟
|
||||
（默认情况下）扫描一次内存，并且打印出新发现的未被引用的对象个数。
|
||||
如果 ``debugfs`` 没有挂载，则执行::
|
||||
|
||||
# mount -t debugfs nodev /sys/kernel/debug/
|
||||
|
||||
显示所有扫描出的可能的内存泄漏的细节信息::
|
||||
|
||||
# cat /sys/kernel/debug/kmemleak
|
||||
|
||||
启动一次中等程度的内存扫描::
|
||||
|
||||
# echo scan > /sys/kernel/debug/kmemleak
|
||||
|
||||
清空当前所有可能的内存泄露列表::
|
||||
|
||||
# echo clear > /sys/kernel/debug/kmemleak
|
||||
|
||||
当再次读取 ``/sys/kernel/debug/kmemleak`` 文件时，将会输出自上次扫描以来检测到的
|
||||
新的内存泄露。
|
||||
|
||||
注意，孤立目标是通过被分配时间来排序的，列表开始的对象可能会导致后续的对象都被
|
||||
识别为孤立对象。
|
||||
|
||||
可以通过写入 ``/sys/kernel/debug/kmemleak`` 文件在运行时修改内存扫描参数。下面是
|
||||
支持的参数：
|
||||
|
||||
|
||||
* off
|
||||
禁用 kmemleak（不可逆）
|
||||
* stack=on
|
||||
开启任务栈扫描（默认）
|
||||
* stack=off
|
||||
禁用任务栈扫描
|
||||
* scan=on
|
||||
开启自动内存扫描线程（默认）
|
||||
* scan=off
|
||||
关闭自动内存扫描线程
|
||||
* scan=<secs>;
|
||||
设定自动内存扫描间隔，以秒为单位（默认值为 600，设置为 0 表示停
|
||||
止自动扫描）
|
||||
* scan
|
||||
触发一次内存扫描
|
||||
* clear
|
||||
通过标记所有当前已报告的未被引用对象为灰，从而清空当前可能的内存泄露列
|
||||
表；如果 kmemleak 被禁用，则释放所有 kmemleak 对象，。
|
||||
* dump=<addr>
|
||||
输出存储在 <addr> 中的对象信息
|
||||
|
||||
可以通过在内核命令行中传递 ``kmemleak=off`` 参数从而在启动时禁用 Kmemleak。
|
||||
|
||||
在 kmemleak 初始化之前就可能会有内存分配或释放，这些操作被存储在一个早期日志缓
|
||||
冲区中。缓冲区的大小通过 CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE 选项配置。
|
||||
|
||||
如果 CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF 被启用，则 kmemleak 默认被禁用。在内核命
|
||||
令行中传递 ``kmemleak=on`` 参数来开启这个功能。
|
||||
|
||||
如果出现 "Error while writing to stdout" 或 "write_loop: Invalid argument" 这样
|
||||
的错误，请确认 kmemleak 被正确启用。
|
||||
|
||||
基础算法
|
||||
--------
|
||||
|
||||
通过 :c:func:`kmalloc`, :c:func:`vmalloc`, :c:func:`kmem_cache_alloc` 以及同类
|
||||
函数均被跟踪，指针，包括一些额外的信息如大小和栈追踪等，都被存储在红黑树中。
|
||||
对应的释放函数调用也被追踪，并从 kmemleak 数据结构中移除相应指针。
|
||||
|
||||
对于一个已分配的内存块，如果通过扫描内存（包括保存寄存器）没有发现任何指针指向
|
||||
它的起始地址或者其中的任何位置，则认为这块内存是孤立的。这意味着内核无法将该内
|
||||
存块的地址传递给一个释放内存函数，这块内存便被认为泄露了。
|
||||
|
||||
扫描算法步骤：
|
||||
|
||||
1. 标记所有对象为白色（最后剩下的白色对象被认为是孤立的）
|
||||
2. 从数据节和栈开始扫描内存，检测每个值是否是红黑树中存储的地址。如果一个指向
|
||||
白色对象的指针被检测到，则将该对象标记为灰色。
|
||||
3. 扫描灰色对象引用的其他对象（有些白色对象可能会变为灰色并被添加到灰名单末尾
|
||||
）直到灰名单为空。
|
||||
4. 剩余的白色对象就被认为是孤立的并通过 /sys/kernel/debug/kmemleak 报告。
|
||||
|
||||
有些指向已分配的内存块的指针存储在内核内部的数据结构中，它们不能被检测为孤立。
|
||||
为了避免这种情况，kmemleak 也存储了指向需要被查找的内存块范围内的任意地址的地址
|
||||
数量，如此一来这些内存便不会被认为泄露。一个例子是 __vmalloc()。
|
||||
|
||||
用 kmemleak 测试特定部分
|
||||
------------------------
|
||||
|
||||
在初始化启动阶段 /sys/kernel/debug/kmemleak 的输出可能会很多，这也可能是你在开发
|
||||
时编写的漏洞百出的代码导致的。为了解决这种情况你可以使用 'clear' 命令来清除
|
||||
/sys/kernel/debug/kmemleak 输出的所有的未引用对象。在执行 'clear' 后执行 'scan'
|
||||
可以发现新的未引用对象，这将会有利你测试代码的特定部分。
|
||||
|
||||
为了用一个空的 kmemleak 测试一个特定部分，执行::
|
||||
|
||||
# echo clear > /sys/kernel/debug/kmemleak
|
||||
... 测试你的内核或者模块 ...
|
||||
# echo scan > /sys/kernel/debug/kmemleak
|
||||
|
||||
然后像平常一样获得报告::
|
||||
|
||||
# cat /sys/kernel/debug/kmemleak
|
||||
|
||||
释放 kmemleak 内核对象
|
||||
----------------------
|
||||
|
||||
为了允许访问先前发现的内存泄露，当用户禁用或发生致命错误导致 kmemleak
|
||||
被禁用时，内核中的 kmemleak 对象不会被释放。这些对象可能会占用很大
|
||||
一部分物理内存。
|
||||
|
||||
在这种情况下，你可以用如下命令回收这些内存::
|
||||
|
||||
# echo clear > /sys/kernel/debug/kmemleak
|
||||
|
||||
Kmemleak API
|
||||
------------
|
||||
|
||||
在 include/linux/kmemleak.h 头文件中查看函数原型：
|
||||
|
||||
- ``kmemleak_init`` - 初始化 kmemleak
|
||||
- ``kmemleak_alloc`` - 通知一个内存块的分配
|
||||
- ``kmemleak_alloc_percpu`` - 通知一个 percpu 类型的内存分配
|
||||
- ``kmemleak_vmalloc`` - 通知一个使用 vmalloc() 的内存分配
|
||||
- ``kmemleak_free`` - 通知一个内存块的释放
|
||||
- ``kmemleak_free_part`` - 通知一个部分的内存释放
|
||||
- ``kmemleak_free_percpu`` - 通知一个 percpu 类型的内存释放
|
||||
- ``kmemleak_update_trace`` - 更新分配对象过程的栈追踪
|
||||
- ``kmemleak_not_leak`` - 标记一个对象内存为未泄露的
|
||||
- ``kmemleak_ignore`` - 不要扫描或报告某个对象未泄露的
|
||||
- ``kmemleak_scan_area`` - 在内存块中添加扫描区域
|
||||
- ``kmemleak_no_scan`` - 不扫描某个内存块
|
||||
- ``kmemleak_erase`` - 在指针变量中移除某个旧的值
|
||||
- ``kmemleak_alloc_recursive`` - 和 kmemleak_alloc 效果相同但会检查是否有递归的
|
||||
内存分配
|
||||
- ``kmemleak_free_recursive`` - 和 kmemleak_free 效果相同但会检查是否有递归的
|
||||
内存释放
|
||||
|
||||
下列函数使用一个物理地址作为对象指针并且只在地址有一个 lowmem 映射时做出相应的
|
||||
行为：
|
||||
|
||||
- ``kmemleak_alloc_phys``
|
||||
- ``kmemleak_free_part_phys``
|
||||
- ``kmemleak_ignore_phys``
|
||||
|
||||
解决假阳性/假阴性
|
||||
-----------------
|
||||
|
||||
假阴性是指由于在内存扫描中有值指向该对象导致 kmemleak 没有报告的实际存在的内存
|
||||
泄露（孤立对象）。为了减少假阴性的出现次数，kmemleak 提供了 kmemleak_ignore，
|
||||
kmemleak_scan_area，kmemleak_no_scan 和 kmemleak_erase 函数（见上）。
|
||||
任务栈也会增加假阴性的数量并且默认不开启对它们的扫描。
|
||||
|
||||
假阳性是对象被误报为内存泄露（孤立对象）。对于已知未泄露的对象，kmemleak
|
||||
提供了 kmemleak_not_leak 函数。同时 kmemleak_ignore 可以用于标记已知不包含任何
|
||||
其他指针的内存块，标记后该内存块不会再被扫描。
|
||||
|
||||
一些被报告的泄露仅仅是暂时的，尤其是在 SMP（对称多处理）系统中，因为其指针
|
||||
暂存在 CPU 寄存器或栈中。Kmemleak 定义了 MSECS_MIN_AGE（默认值为 1000）
|
||||
来表示一个被报告为内存泄露的对象的最小存活时间。
|
||||
|
||||
限制和缺点
|
||||
----------
|
||||
|
||||
主要的缺点是内存分配和释放的性能下降。为了避免其他的损失，只有当
|
||||
/sys/kernel/debug/kmemleak 文件被读取时才会进行内存扫描。无论如何，这个工具是出于
|
||||
调试的目标，性能表现可能不是最重要的。
|
||||
|
||||
为了保持算法简单，kmemleak 寻找指向某个内存块范围中的任何值。这可能会引发假阴性
|
||||
现象的出现。但是，最后一个真正的内存泄露也会变得明显。
|
||||
|
||||
非指针值的数据是假阴性的另一个来源。在将来的版本中，kmemleak 仅仅会扫
|
||||
描已分配结构体中的指针成员。这个特性会解决上述很多的假阴性情况。
|
||||
|
||||
Kmemleak 会报告假阳性。这可能发生在某些被分配的内存块不需要被释放的情况下
|
||||
（某些 init_call 函数中），指针的计算是通过其他方法而不是常规的 container_of 宏
|
||||
或是指针被存储在 kmemleak 没有扫描的地方。
|
||||
|
||||
页分配和 ioremap 不会被追踪。
|
||||
|
||||
使用 kmemleak-test 测试
|
||||
-----------------------
|
||||
|
||||
为了检测是否成功启用了 kmemleak，你可以使用一个故意制造内存泄露的模块
|
||||
kmemleak-test。设置 CONFIG_SAMPLE_KMEMLEAK 为模块（不能作为内建模块使用）
|
||||
并且启动启用了 kmemleak 的内核。加载模块并执行一次扫描::
|
||||
|
||||
# modprobe kmemleak-test
|
||||
# echo scan > /sys/kernel/debug/kmemleak
|
||||
|
||||
注意你可能无法立刻或在第一次扫描后得到结果。当 kmemleak 得到结果，将会输出日
|
||||
志 ``kmemleak: <count of leaks> new suspected memory leaks`` 。然后通过读取文件
|
||||
获取信息::
|
||||
|
||||
# cat /sys/kernel/debug/kmemleak
|
||||
unreferenced object 0xffff89862ca702e8 (size 32):
|
||||
comm "modprobe", pid 2088, jiffies 4294680594 (age 375.486s)
|
||||
hex dump (first 32 bytes):
|
||||
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
|
||||
6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
|
||||
backtrace:
|
||||
[<00000000e0a73ec7>] 0xffffffffc01d2036
|
||||
[<000000000c5d2a46>] do_one_initcall+0x41/0x1df
|
||||
[<0000000046db7e0a>] do_init_module+0x55/0x200
|
||||
[<00000000542b9814>] load_module+0x203c/0x2480
|
||||
[<00000000c2850256>] __do_sys_finit_module+0xba/0xe0
|
||||
[<000000006564e7ef>] do_syscall_64+0x43/0x110
|
||||
[<000000007c873fa6>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
|
||||
...
|
||||
|
||||
用 ``rmmod kmemleak_test`` 移除模块时也会触发
|
||||
kmemleak 的结果输出。
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/dev-tools/ubsan.rst
|
||||
:Translator: Dongliang Mu <dzm91@hust.edu.cn>
|
||||
|
||||
未定义行为消毒剂 - UBSAN
|
||||
====================================
|
||||
|
||||
UBSAN是一种动态未定义行为检查工具。
|
||||
|
||||
UBSAN使用编译时插桩捕捉未定义行为。编译器在可能导致未定义行为的操作前插入特定
|
||||
检测代码。如果检查失败，即检测到未定义行为，__ubsan_handle_* 函数将被调用打印
|
||||
错误信息。
|
||||
|
||||
GCC自4.9.x [1_] （详见 ``-fsanitize=undefined`` 选项及其子选项）版本后引入这
|
||||
一特性。GCC 5.x 版本实现了更多检查器 [2_]。
|
||||
|
||||
报告样例
|
||||
--------------
|
||||
|
||||
::
|
||||
|
||||
================================================================================
|
||||
UBSAN: Undefined behaviour in ../include/linux/bitops.h:110:33
|
||||
shift exponent 32 is to large for 32-bit type 'unsigned int'
|
||||
CPU: 0 PID: 0 Comm: swapper Not tainted 4.4.0-rc1+ #26
|
||||
0000000000000000 ffffffff82403cc8 ffffffff815e6cd6 0000000000000001
|
||||
ffffffff82403cf8 ffffffff82403ce0 ffffffff8163a5ed 0000000000000020
|
||||
ffffffff82403d78 ffffffff8163ac2b ffffffff815f0001 0000000000000002
|
||||
Call Trace:
|
||||
[<ffffffff815e6cd6>] dump_stack+0x45/0x5f
|
||||
[<ffffffff8163a5ed>] ubsan_epilogue+0xd/0x40
|
||||
[<ffffffff8163ac2b>] __ubsan_handle_shift_out_of_bounds+0xeb/0x130
|
||||
[<ffffffff815f0001>] ? radix_tree_gang_lookup_slot+0x51/0x150
|
||||
[<ffffffff8173c586>] _mix_pool_bytes+0x1e6/0x480
|
||||
[<ffffffff83105653>] ? dmi_walk_early+0x48/0x5c
|
||||
[<ffffffff8173c881>] add_device_randomness+0x61/0x130
|
||||
[<ffffffff83105b35>] ? dmi_save_one_device+0xaa/0xaa
|
||||
[<ffffffff83105653>] dmi_walk_early+0x48/0x5c
|
||||
[<ffffffff831066ae>] dmi_scan_machine+0x278/0x4b4
|
||||
[<ffffffff8111d58a>] ? vprintk_default+0x1a/0x20
|
||||
[<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120
|
||||
[<ffffffff830b2240>] setup_arch+0x405/0xc2c
|
||||
[<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120
|
||||
[<ffffffff830ae053>] start_kernel+0x83/0x49a
|
||||
[<ffffffff830ad120>] ? early_idt_handler_array+0x120/0x120
|
||||
[<ffffffff830ad386>] x86_64_start_reservations+0x2a/0x2c
|
||||
[<ffffffff830ad4f3>] x86_64_start_kernel+0x16b/0x17a
|
||||
================================================================================
|
||||
|
||||
用法
|
||||
-----
|
||||
|
||||
使用如下内核配置启用UBSAN::
|
||||
|
||||
CONFIG_UBSAN=y
|
||||
|
||||
使用如下内核配置检查整个内核::
|
||||
|
||||
CONFIG_UBSAN_SANITIZE_ALL=y
|
||||
|
||||
为了在特定文件或目录启动代码插桩，需要在相应的内核Makefile中添加一行类似内容:
|
||||
|
||||
- 单文件（如main.o）::
|
||||
|
||||
UBSAN_SANITIZE_main.o := y
|
||||
|
||||
- 一个目录中的所有文件::
|
||||
|
||||
UBSAN_SANITIZE := y
|
||||
|
||||
即使设置了``CONFIG_UBSAN_SANITIZE_ALL=y``，为了避免文件被插桩，可使用::
|
||||
|
||||
UBSAN_SANITIZE_main.o := n
|
||||
|
||||
与::
|
||||
|
||||
UBSAN_SANITIZE := n
|
||||
|
||||
未对齐的内存访问检测可通过开启独立选项 - CONFIG_UBSAN_ALIGNMENT 检测。
|
||||
该选项在支持未对齐访问的架构上(CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y)
|
||||
默认为关闭。该选项仍可通过内核配置启用，但它将产生大量的UBSAN报告。
|
||||
|
||||
参考文献
|
||||
----------
|
||||
|
||||
.. _1: https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/Debugging-Options.html
|
||||
.. _2: https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
|
||||
.. _3: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
|
||||
|
|
@ -24,8 +24,8 @@
|
|||
上的linux-doc邮件列表。
|
||||
|
||||
顺便说下，中文文档也需要遵守内核编码风格，风格中中文和英文的主要不同就是中文
|
||||
的字符标点占用两个英文字符宽度， 所以，当英文要求不要超过每行100个字符时，
|
||||
中文就不要超过50个字符。另外，也要注意'-'，'=' 等符号与相关标题的对齐。在将
|
||||
的字符标点占用两个英文字符宽度，所以，当英文要求不要超过每行100个字符时，
|
||||
中文就不要超过50个字符。另外，也要注意'-'，'='等符号与相关标题的对齐。在将
|
||||
补丁提交到社区之前，一定要进行必要的 ``checkpatch.pl`` 检查和编译测试。
|
||||
|
||||
与Linux 内核社区一起工作
|
||||
|
|
|
|||
|
|
@ -0,0 +1,89 @@
|
|||
.. include:: ../disclaimer-zh_CN.rst
|
||||
|
||||
:Original: Documentation/process/cve.rst
|
||||
:Translator: Dongliang Mu <dzm91@hust.edu.cn>
|
||||
|
||||
====
|
||||
CVEs
|
||||
====
|
||||
|
||||
Common Vulnerabilities and Exposure (CVE®) 编号是一种明确的方式来
|
||||
识别、定义和登记公开披露的安全漏洞。随着时间的推移，它们在内核项目中的实用性
|
||||
已经下降，CVE编号经常以不适当的方式和不适当的原因被分配。因此，内核开发社区
|
||||
倾向于避免使用它们。然而，分配CVE与其他形式的安全标识符的持续压力，以及内核
|
||||
社区之外的个人和公司的持续滥用，已经清楚地表明内核社区应该控制这些CVE分配。
|
||||
|
||||
Linux内核开发团队确实有能力为潜在的Linux内核安全问题分配CVE。CVE的分配
|
||||
独立于 :doc:`安全漏洞报送流程</process/security-bugs>`。
|
||||
|
||||
所有分配给Linux内核的CVE列表都可以在linux-cve邮件列表的存档中找到，如
|
||||
https://lore.kernel.org/linux-cve-announce/ 所示。如果想获得已分配
|
||||
CVE的通知，请“订阅”该邮件列表。要获得分配的CVE通知，请订阅该邮件列表：
|
||||
`订阅 <https://subspace.kernel.org/subscribing.html>`_。
|
||||
|
||||
过程
|
||||
=======
|
||||
|
||||
作为正常稳定发布过程的一部分，可能存在安全问题的内核更改由负责CVE编号分配
|
||||
的开发人员识别，并自动为其分配CVE编号。这些CVE分配会作为经常性的通告经常
|
||||
发布在linux-cve-announce邮件列表上。
|
||||
|
||||
注意，由于Linux内核在系统中的特殊地位，几乎任何漏洞都可能被利用来危害内核
|
||||
的安全性，但是当漏洞被修复后，利用的可能性通常不明显。因此，CVE分配团队过于
|
||||
谨慎，并将CVE编号分配给他们识别的任何漏洞修复。这就解释了为什么Linux内核
|
||||
团队会发布大量的CVE。
|
||||
|
||||
如果CVE分配团队错过了任何用户认为应该分配CVE的特定修复，请发送电子邮件到
|
||||
<cve@kernel.org>，那里的团队将与您一起工作。请注意，任何潜在的安全问题
|
||||
不应被发送到此邮箱，它仅用于为已发布的内核树中的漏洞修复分配CVE。如果你觉得
|
||||
自己发现了一个未修复的安全问题，请按照 :doc:`安全漏洞报送流程
|
||||
</process/security-bugs>` 发送到Linux内核社区。
|
||||
|
||||
Linux内核不会给未修复的安全问题自动分配CVE；只有在安全修复可用且应用于
|
||||
稳定内核树后，CVE分配才会自动发生，并且它将通过安全修复的Git提交编号进行
|
||||
跟踪。如果有人希望在提交安全修复之前分配CVE，请联系内核CVE分配团队，从
|
||||
他们的一批保留编号中获得相应的CVE编号。
|
||||
|
||||
对于目前没有得到稳定与长期维护内核团队积极支持的内核版本中发现的任何问题，
|
||||
都不会分配CVEs。当前支持的内核分支列表可以在 https://kernel.org/releases.html
|
||||
上找到。
|
||||
|
||||
被分配CVE的争论
|
||||
=========================
|
||||
|
||||
对于为特定内核修改分配的CVE，其争论或修改的权限仅属于受影响子系统的维护者。
|
||||
这一原则确保了漏洞报告的高度准确性和可问责性。只有那些具有深厚专业知识和
|
||||
对子系统深入了解的维护人员，才能有效评估内核漏洞的有效性和范围，并确定其适当的
|
||||
CVE指定策略。在此指定权限之外，任何争论或修改CVE的尝试都可能导致混乱、
|
||||
不准确的报告，并最终危及系统。
|
||||
|
||||
无效的CVE
|
||||
============
|
||||
|
||||
如果发现的安全问题存在于仅由某Linux发行版支持的Linux内核中，即安全问题是
|
||||
由于Linux发行版所做的更改导致，或者Linux的发行版内核版本不再是Linux内核
|
||||
社区支持的内核版本，那么Linux内核CVE团队将不能分配CVE，必须从Linux
|
||||
发行版本身请求。
|
||||
|
||||
内核CVE分配团队以外的任何团队对Linux内核支持版本分配的CVE都不应被
|
||||
视为有效CVE。请通知内核CVE分配团队，以便他们可以通过CNA修复措施使
|
||||
这些条目失效。
|
||||
|
||||
特定CVE的适用性
|
||||
==============================
|
||||
|
||||
由于Linux内核可以以许多不同方式使用，外部用户可以通过许多不同方式访问它，或者
|
||||
根本没有访问，因此任何特定CVE的适用性取决于Linux用户，而不是内核CVE分配团队。
|
||||
请不要与我们联系来尝试确定任何特定CVE的适用性。
|
||||
|
||||
此外，由于源代码树非常大，而任何一个系统都只使用源代码树的一小部分，因此任何
|
||||
Linux用户都应该意识到，大量分配的CVEs与他们的系统无关。
|
||||
|
||||
简而言之，我们不知道您的用例，也不知道您使用的是内核的哪个部分，因此我们无法
|
||||
确定特定的CVE是否与您的系统相关。
|
||||
|
||||
与往常一样，最好采用所有发布的内核更改，因为它们是由许多社区成员在一个统一的
|
||||
整体中一起进行测试的，而不是作为个别的精选更改。还要注意，对于许多安全问题来
|
||||
说，整体问题的解决方案并不是在单个更改中找到的，而是在彼此之上的许多修复的总
|
||||
和。理想情况下，CVE将被分配给所有问题的所有修复，但有时我们将无法注意到一些
|
||||
修复，因此某些修复可能在没有CVE的情况下被采取。
|
||||
|
|
@ -48,6 +48,7 @@ TODOLIST:
|
|||
:maxdepth: 1
|
||||
|
||||
embargoed-hardware-issues
|
||||
cve
|
||||
|
||||
TODOLIST:
|
||||
|
||||
|
|
|
|||
|
|
@ -333,10 +333,10 @@ Linus 和其他的内核开发者需要阅读和评论你提交的改动。对
|
|||
未参与其开发。签署链应当反映补丁传播到维护者并最终传播到Linus所经过的 **真实**
|
||||
路径，首个签署指明单个作者的主要作者身份。
|
||||
|
||||
何时使用Acked-by:，CC:，和Co-Developed by:
|
||||
何时使用Acked-by:，Cc:，和Co-developed-by:
|
||||
------------------------------------------
|
||||
|
||||
Singed-off-by: 标签表示签名者参与了补丁的开发，或者他/她在补丁的传递路径中。
|
||||
Signed-off-by: 标签表示签名者参与了补丁的开发，或者他/她在补丁的传递路径中。
|
||||
|
||||
如果一个人没有直接参与补丁的准备或处理，但希望表示并记录他们对补丁的批准/赞成，
|
||||
那么他们可以要求在补丁的变更日志中添加一个Acked-by:。
|
||||
|
|
@ -358,8 +358,8 @@ Acked-by：不一定表示对整个补丁的确认。例如，如果一个补丁
|
|||
Co-developed-by: 声明补丁是由多个开发人员共同创建的；当几个人在一个补丁上工
|
||||
作时，它用于给出共同作者（除了From:所给出的作者之外）。因为Co-developed-by:
|
||||
表示作者身份，所以每个Co-developed-by:必须紧跟在相关合作作者的签署之后。标准
|
||||
签署程序要求Singed-off-by:标签的顺序应尽可能反映补丁的时间历史，无论作者是通
|
||||
过From:还是Co-developed-by:表明。值得注意的是，最后一个Singed-off-by:必须是
|
||||
签署程序要求Signed-off-by:标签的顺序应尽可能反映补丁的时间历史，无论作者是通
|
||||
过From:还是Co-developed-by:表明。值得注意的是，最后一个Signed-off-by:必须是
|
||||
提交补丁的开发人员。
|
||||
|
||||
注意，如果From:作者也是电子邮件标题的From:行中列出的人，则From:标签是可选的。
|
||||
|
|
|
|||
|
|
@ -16,8 +16,12 @@
|
|||
|
||||
下面是目前可以工作的架构的一般总结。支持程度与 ``MAINTAINERS`` 文件中的``S`` 值相对应:
|
||||
|
||||
============ ================ ==============================================
|
||||
架构 支持水平 限制因素
|
||||
============ ================ ==============================================
|
||||
``x86`` Maintained 只有 ``x86_64``
|
||||
============ ================ ==============================================
|
||||
============= ================ ==============================================
|
||||
架构 支持水平 限制因素
|
||||
============= ================ ==============================================
|
||||
``arm64`` Maintained 只有小端序
|
||||
``loongarch`` Maintained \-
|
||||
``riscv`` Maintained 只有 ``riscv64``
|
||||
``um`` Maintained 只有 ``x86_64``
|
||||
``x86`` Maintained 只有 ``x86_64``
|
||||
============= ================ ==============================================
|
||||
|
|
|
|||
|
|
@ -157,6 +157,18 @@ https://commonmark.org/help/
|
|||
|
||||
https://doc.rust-lang.org/rustdoc/how-to-write-documentation.html
|
||||
|
||||
此外，内核支持通过在链接目标前添加 ``srctree/`` 来创建相对于源代码树的链接。例如:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
//! C header: [`include/linux/printk.h`](srctree/include/linux/printk.h)
|
||||
|
||||
或者:
|
||||
|
||||
.. code-block:: rust
|
||||
|
||||
/// [`struct mutex`]: srctree/include/linux/mutex.h
|
||||
|
||||
|
||||
命名
|
||||
----
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ Rust内核代码使用其内置的文档生成器 ``rustdoc`` 进行记录。
|
|||
|
||||
要在你的网络浏览器中本地阅读该文档，请运行如::
|
||||
|
||||
xdg-open rust/doc/kernel/index.html
|
||||
xdg-open Documentation/output/rust/rustdoc/kernel/index.html
|
||||
|
||||
要了解如何编写文档，请看 coding-guidelines.rst 。
|
||||
|
||||
|
|
|
|||
|
|
@ -37,13 +37,18 @@ rustc
|
|||
需要一个特定版本的Rust编译器。较新的版本可能会也可能不会工作，因为就目前而言，内核依赖
|
||||
于一些不稳定的Rust特性。
|
||||
|
||||
如果使用的是 ``rustup`` ，请进入检出的源代码目录并运行::
|
||||
如果使用的是 ``rustup`` ，请进入内核编译目录（或者用 ``--path=<build-dir>`` 参数
|
||||
来 ``设置`` sub-command)并运行::
|
||||
|
||||
rustup override set $(scripts/min-tool-version.sh rustc)
|
||||
|
||||
或者从以下网址获取一个独立的安装程序或安装 ``rustup`` ：
|
||||
+这将配置你的工作目录使用正确版本的 ``rustc``，而不影响你的默认工具链。
|
||||
|
||||
https://www.rust-lang.org
|
||||
请注意覆盖应用当前的工作目录（和它的子目录）。
|
||||
|
||||
如果你使用 ``rustup``， 可以从下面的链接拉取一个单独的安装程序:
|
||||
|
||||
https://forge.rust-lang.org/infra/other-installation-methods.html#standalone
|
||||
|
||||
|
||||
Rust标准库源代码
|
||||
|
|
@ -57,21 +62,23 @@ Rust标准库的源代码是必需的，因为构建系统会交叉编译 ``core
|
|||
|
||||
这些组件是按工具链安装的，因此以后升级Rust编译器版本需要重新添加组件。
|
||||
|
||||
否则，如果使用独立的安装程序，可以将Rust仓库克隆到工具链的安装文件夹中::
|
||||
否则，如果使用独立的安装程序，可以将Rust源码树下载到安装工具链的文件夹中::
|
||||
|
||||
git clone --recurse-submodules \
|
||||
--branch $(scripts/min-tool-version.sh rustc) \
|
||||
https://github.com/rust-lang/rust \
|
||||
$(rustc --print sysroot)/lib/rustlib/src/rust
|
||||
curl -L "https://static.rust-lang.org/dist/rust-src-$(scripts/min-tool-version.sh rustc).tar.gz" |
|
||||
tar -xzf - -C "$(rustc --print sysroot)/lib" \
|
||||
"rust-src-$(scripts/min-tool-version.sh rustc)/rust-src/lib/" \
|
||||
--strip-components=3
|
||||
|
||||
在这种情况下，以后升级Rust编译器版本需要手动更新这个克隆的仓库。
|
||||
在这种情况下，以后升级Rust编译器版本需要手动更新这个源代码树（这可以通过移除
|
||||
``$(rustc --print sysroot)/lib/rustlib/src/rust`` ，然后重新执行上
|
||||
面的命令做到）。
|
||||
|
||||
|
||||
libclang
|
||||
********
|
||||
|
||||
``bindgen`` 使用 ``libclang`` （LLVM的一部分）来理解内核中的C代码，这意味着需要安
|
||||
装LLVM；同在开启 ``CC=clang`` 或 ``LLVM=1`` 时编译内核一样。
|
||||
装LLVM；同在开启``LLVM=1`` 时编译内核一样。
|
||||
|
||||
Linux发行版中可能会有合适的包，所以最好先检查一下。
|
||||
|
||||
|
|
@ -94,7 +101,20 @@ bindgen
|
|||
|
||||
通过以下方式安装它（注意，这将从源码下载并构建该工具）::
|
||||
|
||||
cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen
|
||||
cargo install --locked --version $(scripts/min-tool-version.sh bindgen) bindgen-cli
|
||||
|
||||
``bindgen`` 需要找到合适的 ``libclang`` 才能工作。如果没有找到（或者找到的
|
||||
``libclang`` 与应该使用的 ``libclang`` 不同），则可以使用 ``clang-sys``
|
||||
理解的环境变量（Rust绑定创建的 ``bindgen`` 用来访问 ``libclang``）:
|
||||
|
||||
|
||||
* ``LLVM_CONFIG_PATH`` 可以指向一个 ``llvm-config`` 可执行文件。
|
||||
|
||||
* 或者 ``LIBCLANG_PATH`` 可以指向 ``libclang`` 共享库或包含它的目录。
|
||||
|
||||
* 或者 ``CLANG_PATH`` 可以指向 ``clang`` 可执行文件。
|
||||
|
||||
详情请参阅 ``clang-sys`` 的文档:
|
||||
|
||||
|
||||
开发依赖
|
||||
|
|
@ -163,7 +183,9 @@ rust-analyzer
|
|||
一起使用，以实现语法高亮、补全、转到定义和其他功能。
|
||||
|
||||
``rust-analyzer`` 需要一个配置文件， ``rust-project.json``, 它可以由 ``rust-analyzer``
|
||||
Make 目标生成。
|
||||
Make 目标生成::
|
||||
|
||||
make LLVM=1 rust-analyzer
|
||||
|
||||
|
||||
配置
|
||||
|
|
@ -189,10 +211,6 @@ Rust支持（CONFIG_RUST）需要在 ``General setup`` 菜单中启用。在其
|
|||
|
||||
make LLVM=1
|
||||
|
||||
对于不支持完整LLVM工具链的架构，使用::
|
||||
|
||||
make CC=clang
|
||||
|
||||
使用GCC对某些配置也是可行的，但目前它是非常试验性的。
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ Linux內核補丁提交檢查單
|
|||
|
||||
c) 使用 ``O=builddir`` 時可以成功編譯
|
||||
|
||||
d) 任何 Doucmentation/ 下的變更都能成功構建且不引入新警告/錯誤。
|
||||
d) 任何 Documentation/ 下的變更都能成功構建且不引入新警告/錯誤。
|
||||
用 ``make htmldocs`` 或 ``make pdfdocs`` 檢驗構建情況並修復問題。
|
||||
|
||||
3) 通過使用本地交叉編譯工具或其他一些構建設施在多個CPU體系結構上構建。
|
||||
|
|
|
|||
|
|
@ -334,10 +334,10 @@ Linus 和其他的內核開發者需要閱讀和評論你提交的改動。對
|
|||
未參與其開發。簽署鏈應當反映補丁傳播到維護者並最終傳播到Linus所經過的 **真實**
|
||||
路徑，首個簽署指明單個作者的主要作者身份。
|
||||
|
||||
何時使用Acked-by:，CC:，和Co-Developed by:
|
||||
何時使用Acked-by:，Cc:，和Co-developed-by:
|
||||
------------------------------------------
|
||||
|
||||
Singed-off-by: 標籤表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。
|
||||
Signed-off-by: 標籤表示簽名者參與了補丁的開發，或者他/她在補丁的傳遞路徑中。
|
||||
|
||||
如果一個人沒有直接參與補丁的準備或處理，但希望表示並記錄他們對補丁的批准/贊成，
|
||||
那麼他們可以要求在補丁的變更日誌中添加一個Acked-by:。
|
||||
|
|
@ -359,8 +359,8 @@ Acked-by：不一定表示對整個補丁的確認。例如，如果一個補丁
|
|||
Co-developed-by: 聲明補丁是由多個開發人員共同創建的；當幾個人在一個補丁上工
|
||||
作時，它用於給出共同作者（除了From:所給出的作者之外）。因爲Co-developed-by:
|
||||
表示作者身份，所以每個Co-developed-by:必須緊跟在相關合作作者的簽署之後。標準
|
||||
簽署程序要求Singed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
|
||||
過From:還是Co-developed-by:表明。值得注意的是，最後一個Singed-off-by:必須是
|
||||
簽署程序要求Signed-off-by:標籤的順序應儘可能反映補丁的時間歷史，無論作者是通
|
||||
過From:還是Co-developed-by:表明。值得注意的是，最後一個Signed-off-by:必須是
|
||||
提交補丁的開發人員。
|
||||
|
||||
注意，如果From:作者也是電子郵件標題的From:行中列出的人，則From:標籤是可選的。
|
||||
|
|
|
|||
|
|
@ -993,7 +993,7 @@ F: drivers/video/fbdev/geode/
|
|||
|
||||
AMD HSMP DRIVER
|
||||
M: Naveen Krishna Chatradhi <naveenkrishna.chatradhi@amd.com>
|
||||
R: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
R: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
L: platform-driver-x86@vger.kernel.org
|
||||
S: Maintained
|
||||
F: Documentation/arch/x86/amd_hsmp.rst
|
||||
|
|
@ -5376,7 +5376,7 @@ F: drivers/usb/atm/cxacru.c
|
|||
|
||||
CONFIDENTIAL COMPUTING THREAT MODEL FOR X86 VIRTUALIZATION (SNP/TDX)
|
||||
M: Elena Reshetova <elena.reshetova@intel.com>
|
||||
M: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
M: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
S: Maintained
|
||||
F: Documentation/security/snp-tdx-threat-model.rst
|
||||
|
||||
|
|
@ -6425,6 +6425,7 @@ S: Maintained
|
|||
P: Documentation/doc-guide/maintainer-profile.rst
|
||||
T: git git://git.lwn.net/linux.git docs-next
|
||||
F: Documentation/
|
||||
F: scripts/check-variable-fonts.sh
|
||||
F: scripts/documentation-file-ref-check
|
||||
F: scripts/kernel-doc
|
||||
F: scripts/sphinx-pre-install
|
||||
|
|
@ -10626,7 +10627,7 @@ S: Orphan
|
|||
F: drivers/video/fbdev/imsttfb.c
|
||||
|
||||
INDEX OF FURTHER KERNEL DOCUMENTATION
|
||||
M: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
M: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
S: Maintained
|
||||
F: Documentation/process/kernel-docs.rst
|
||||
|
||||
|
|
@ -20713,7 +20714,7 @@ Q: http://patchwork.linuxtv.org/project/linux-media/list/
|
|||
F: drivers/media/dvb-frontends/sp2*
|
||||
|
||||
SPANISH DOCUMENTATION
|
||||
M: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
M: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
|
||||
R: Avadhut Naik <avadhut.naik@amd.com>
|
||||
S: Maintained
|
||||
F: Documentation/translations/sp_SP/
|
||||
|
|
|
|||
|
|
@ -333,10 +333,9 @@ config SHUFFLE_PAGE_ALLOCATOR
|
|||
|
||||
While the randomization improves cache utilization it may
|
||||
negatively impact workloads on platforms without a cache. For
|
||||
this reason, by default, the randomization is enabled only
|
||||
after runtime detection of a direct-mapped memory-side-cache.
|
||||
Otherwise, the randomization may be force enabled with the
|
||||
'page_alloc.shuffle' kernel command line parameter.
|
||||
this reason, by default, the randomization is not enabled even
|
||||
if SHUFFLE_PAGE_ALLOCATOR=y. The randomization may be force enabled
|
||||
with the 'page_alloc.shuffle' kernel command line parameter.
|
||||
|
||||
Say Y if unsure.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,115 @@
|
|||
#!/bin/sh
|
||||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
# Copyright (C) Akira Yokosawa, 2024
|
||||
#
|
||||
# For "make pdfdocs", reports of build errors of translations.pdf started
|
||||
# arriving early 2024 [1, 2]. It turned out that Fedora and openSUSE
|
||||
# tumbleweed have started deploying variable-font [3] format of "Noto CJK"
|
||||
# fonts [4, 5]. For PDF, a LaTeX package named xeCJK is used for CJK
|
||||
# (Chinese, Japanese, Korean) pages. xeCJK requires XeLaTeX/XeTeX, which
|
||||
# does not (and likely never will) understand variable fonts for historical
|
||||
# reasons.
|
||||
#
|
||||
# The build error happens even when both of variable- and non-variable-format
|
||||
# fonts are found on the build system. To make matters worse, Fedora enlists
|
||||
# variable "Noto CJK" fonts in the requirements of langpacks-ja, -ko, -zh_CN,
|
||||
# -zh_TW, etc. Hence developers who have interest in CJK pages are more
|
||||
# likely to encounter the build errors.
|
||||
#
|
||||
# This script is invoked from the error path of "make pdfdocs" and emits
|
||||
# suggestions if variable-font files of "Noto CJK" fonts are in the list of
|
||||
# fonts accessible from XeTeX.
|
||||
#
|
||||
# References:
|
||||
# [1]: https://lore.kernel.org/r/8734tqsrt7.fsf@meer.lwn.net/
|
||||
# [2]: https://lore.kernel.org/r/1708585803.600323099@f111.i.mail.ru/
|
||||
# [3]: https://en.wikipedia.org/wiki/Variable_font
|
||||
# [4]: https://fedoraproject.org/wiki/Changes/Noto_CJK_Variable_Fonts
|
||||
# [5]: https://build.opensuse.org/request/show/1157217
|
||||
#
|
||||
#===========================================================================
|
||||
# Workarounds for building translations.pdf
|
||||
#===========================================================================
|
||||
#
|
||||
# * Denylist "variable font" Noto CJK fonts.
|
||||
# - Create $HOME/deny-vf/fontconfig/fonts.conf from template below, with
|
||||
# tweaks if necessary. Remove leading "# ".
|
||||
# - Path of fontconfig/fonts.conf can be overridden by setting an env
|
||||
# variable FONTS_CONF_DENY_VF.
|
||||
#
|
||||
# * Template:
|
||||
# -----------------------------------------------------------------
|
||||
# <?xml version="1.0"?>
|
||||
# <!DOCTYPE fontconfig SYSTEM "urn:fontconfig:fonts.dtd">
|
||||
# <fontconfig>
|
||||
# <!--
|
||||
# Ignore variable-font glob (not to break xetex)
|
||||
# -->
|
||||
# <selectfont>
|
||||
# <rejectfont>
|
||||
# <!--
|
||||
# for Fedora
|
||||
# -->
|
||||
# <glob>/usr/share/fonts/google-noto-*-cjk-vf-fonts</glob>
|
||||
# <!--
|
||||
# for openSUSE tumbleweed
|
||||
# -->
|
||||
# <glob>/usr/share/fonts/truetype/Noto*CJK*-VF.otf</glob>
|
||||
# </rejectfont>
|
||||
# </selectfont>
|
||||
# </fontconfig>
|
||||
# -----------------------------------------------------------------
|
||||
#
|
||||
# The denylisting is activated for "make pdfdocs".
|
||||
#
|
||||
# * For skipping CJK pages in PDF
|
||||
# - Uninstall texlive-xecjk.
|
||||
# Denylisting is not needed in this case.
|
||||
#
|
||||
# * For printing CJK pages in PDF
|
||||
# - Need non-variable "Noto CJK" fonts.
|
||||
# * Fedora
|
||||
# - google-noto-sans-cjk-fonts
|
||||
# - google-noto-serif-cjk-fonts
|
||||
# * openSUSE tumbleweed
|
||||
# - Non-variable "Noto CJK" fonts are not available as distro packages
|
||||
# as of April, 2024. Fetch a set of font files from upstream Noto
|
||||
# CJK Font released at:
|
||||
# https://github.com/notofonts/noto-cjk/tree/main/Sans#super-otc
|
||||
# and at:
|
||||
# https://github.com/notofonts/noto-cjk/tree/main/Serif#super-otc
|
||||
# , then uncompress and deploy them.
|
||||
# - Remember to update fontconfig cache by running fc-cache.
|
||||
#
|
||||
# !!! Caution !!!
|
||||
# Uninstalling "variable font" packages can be dangerous.
|
||||
# They might be depended upon by other packages important for your work.
|
||||
# Denylisting should be less invasive, as it is effective only while
|
||||
# XeLaTeX runs in "make pdfdocs".
|
||||
|
||||
# Default per-user fontconfig path (overridden by env variable)
|
||||
: ${FONTS_CONF_DENY_VF:=$HOME/deny-vf}
|
||||
|
||||
export XDG_CONFIG_HOME=${FONTS_CONF_DENY_VF}
|
||||
|
||||
notocjkvffonts=`fc-list : file family variable | \
|
||||
grep 'variable=True' | \
|
||||
grep -E -e 'Noto (Sans|Sans Mono|Serif) CJK' | \
|
||||
sed -e 's/^/ /' -e 's/: Noto S.*$//' | sort | uniq`
|
||||
|
||||
if [ "x$notocjkvffonts" != "x" ] ; then
|
||||
echo '============================================================================='
|
||||
echo 'XeTeX is confused by "variable font" files listed below:'
|
||||
echo "$notocjkvffonts"
|
||||
echo
|
||||
echo 'For CJK pages in PDF, they need to be hidden from XeTeX by denylisting.'
|
||||
echo 'Or, CJK pages can be skipped by uninstalling texlive-xecjk.'
|
||||
echo
|
||||
echo 'For more info on denylisting, other options, and variable font, see header'
|
||||
echo 'comments of scripts/check-variable-fonts.sh.'
|
||||
echo '============================================================================='
|
||||
fi
|
||||
|
||||
# As this script is invoked from Makefile's error path, always error exit
|
||||
# regardless of whether any variable font is discovered or not.
|
||||
exit 1
|
||||
|
|
@ -62,7 +62,7 @@ my $anon_struct_union = 0;
|
|||
|
||||
# match expressions used to find embedded type information
|
||||
my $type_constant = '\b``([^\`]+)``\b';
|
||||
my $type_constant2 = '\%([-_\w]+)';
|
||||
my $type_constant2 = '\%([-_*\w]+)';
|
||||
my $type_func = '(\w+)\(\)';
|
||||
my $type_param = '\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
|
||||
my $type_param_ref = '([\!~\*]?)\@(\w*((\.\w+)|(->\w+))*(\.\.\.)?)';
|
||||
|
|
@ -1151,7 +1151,8 @@ sub dump_struct($$) {
|
|||
# - first eat non-declaration parameters and rewrite for final match
|
||||
# - then remove macro, outer parens, and trailing semicolon
|
||||
$members =~ s/\bstruct_group\s*\(([^,]*,)/STRUCT_GROUP(/gos;
|
||||
$members =~ s/\bstruct_group_(attr|tagged)\s*\(([^,]*,){2}/STRUCT_GROUP(/gos;
|
||||
$members =~ s/\bstruct_group_attr\s*\(([^,]*,){2}/STRUCT_GROUP(/gos;
|
||||
$members =~ s/\bstruct_group_tagged\s*\(([^,]*),([^,]*),/struct $1 $2; STRUCT_GROUP(/gos;
|
||||
$members =~ s/\b__struct_group\s*\(([^,]*,){3}/STRUCT_GROUP(/gos;
|
||||
$members =~ s/\bSTRUCT_GROUP(\(((?:(?>[^)(]+)|(?1))*)\))[^;]*;/$2/gos;
|
||||
|
||||
|
|
|
|||
|
|
@ -514,6 +514,7 @@ sub give_mageia_hints()
|
|||
{
|
||||
my %map = (
|
||||
"python-sphinx" => "python3-sphinx",
|
||||
"yaml" => "python3-yaml",
|
||||
"virtualenv" => "python3-virtualenv",
|
||||
"dot" => "graphviz",
|
||||
"convert" => "ImageMagick",
|
||||
|
|
@ -557,10 +558,11 @@ sub give_mageia_hints()
|
|||
sub give_arch_linux_hints()
|
||||
{
|
||||
my %map = (
|
||||
"yaml" => "python-yaml",
|
||||
"virtualenv" => "python-virtualenv",
|
||||
"dot" => "graphviz",
|
||||
"convert" => "imagemagick",
|
||||
"xelatex" => "texlive-bin",
|
||||
"xelatex" => "texlive-xetex",
|
||||
"latexmk" => "texlive-core",
|
||||
"rsvg-convert" => "extra/librsvg",
|
||||
);
|
||||
|
|
@ -587,6 +589,7 @@ sub give_arch_linux_hints()
|
|||
sub give_gentoo_hints()
|
||||
{
|
||||
my %map = (
|
||||
"yaml" => "dev-python/pyyaml",
|
||||
"virtualenv" => "dev-python/virtualenv",
|
||||
"dot" => "media-gfx/graphviz",
|
||||
"convert" => "media-gfx/imagemagick",
|
||||
|
|
|
|||
Loading…
Reference in New Issue