Merge "Merge keystone/android-mainline-keystone-qcom-release.5.19-rc8 (ea7c365) into msm-pineapple"
This commit is contained in:
qctecmdr
Gerrit - the friendly Code Review server
commit
cdd9e3d222
@ -260,6 +260,15 @@ Description:
|
||||
for discards, and don't read this file.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/dma_alignment
|
||||
Date: May 2022
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
Reports the alignment that user space addresses must have to be
|
||||
used for raw block device access with O_DIRECT and other driver
|
||||
specific passthrough mechanisms.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/fua
|
||||
Date: May 2018
|
||||
Contact: linux-block@vger.kernel.org
|
||||
|
||||
@ -938,3 +938,12 @@ Description:
|
||||
- 1: enable
|
||||
|
||||
RW
|
||||
|
||||
What: /sys/class/hwmon/hwmonX/device/pec
|
||||
Description:
|
||||
PEC support on I2C devices
|
||||
|
||||
- 0, off, n: disable
|
||||
- 1, on, y: enable
|
||||
|
||||
RW
|
||||
|
||||
@ -493,12 +493,13 @@ What: /sys/devices/system/cpu/cpuX/regs/
|
||||
/sys/devices/system/cpu/cpuX/regs/identification/
|
||||
/sys/devices/system/cpu/cpuX/regs/identification/midr_el1
|
||||
/sys/devices/system/cpu/cpuX/regs/identification/revidr_el1
|
||||
/sys/devices/system/cpu/cpuX/regs/identification/smidr_el1
|
||||
Date: June 2016
|
||||
Contact: Linux ARM Kernel Mailing list <linux-arm-kernel@lists.infradead.org>
|
||||
Description: AArch64 CPU registers
|
||||
|
||||
'identification' directory exposes the CPU ID registers for
|
||||
identifying model and revision of the CPU.
|
||||
identifying model and revision of the CPU and SMCU.
|
||||
|
||||
What: /sys/devices/system/cpu/aarch32_el0
|
||||
Date: May 2021
|
||||
|
||||
49
Documentation/ABI/testing/sysfs-driver-qat
Normal file
49
Documentation/ABI/testing/sysfs-driver-qat
Normal file
@ -0,0 +1,49 @@
|
||||
What: /sys/bus/pci/devices/<BDF>/qat/state
|
||||
Date: June 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RW) Reports the current state of the QAT device. Write to
|
||||
the file to start or stop the device.
|
||||
|
||||
The values are:
|
||||
|
||||
* up: the device is up and running
|
||||
* down: the device is down
|
||||
|
||||
|
||||
It is possible to transition the device from up to down only
|
||||
if the device is up and vice versa.
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat/cfg_services
|
||||
Date: June 2022
|
||||
KernelVersion: 5.20
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RW) Reports the current configuration of the QAT device.
|
||||
Write to the file to change the configured services.
|
||||
|
||||
The values are:
|
||||
|
||||
* sym;asym: the device is configured for running crypto
|
||||
services
|
||||
* dc: the device is configured for running compression services
|
||||
|
||||
It is possible to set the configuration only if the device
|
||||
is in the `down` state (see /sys/bus/pci/devices/<BDF>/qat/state)
|
||||
|
||||
The following example shows how to change the configuration of
|
||||
a device configured for running crypto services in order to
|
||||
run data compression::
|
||||
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/state
|
||||
up
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
|
||||
sym;asym
|
||||
# echo down > /sys/bus/pci/devices/<BDF>/qat/state
|
||||
# echo dc > /sys/bus/pci/devices/<BDF>/qat/cfg_services
|
||||
# echo up > /sys/bus/pci/devices/<BDF>/qat/state
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/cfg_services
|
||||
dc
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
@ -12,8 +12,9 @@ Description:
|
||||
configuration data to the guest userspace.
|
||||
|
||||
The authoritative guest-side hardware interface documentation
|
||||
to the fw_cfg device can be found in "docs/specs/fw_cfg.txt"
|
||||
in the QEMU source tree.
|
||||
to the fw_cfg device can be found in "docs/specs/fw_cfg.rst"
|
||||
in the QEMU source tree, or online at:
|
||||
https://qemu-project.gitlab.io/qemu/specs/fw_cfg.html
|
||||
|
||||
**SysFS fw_cfg Interface**
|
||||
|
||||
|
||||
@ -1,23 +1,22 @@
|
||||
config WARN_MISSING_DOCUMENTS
|
||||
|
||||
bool "Warn if there's a missing documentation file"
|
||||
depends on COMPILE_TEST
|
||||
help
|
||||
It is not uncommon that a document gets renamed.
|
||||
This option makes the Kernel to check for missing dependencies,
|
||||
warning when something is missing. Works only if the Kernel
|
||||
is built from a git tree.
|
||||
It is not uncommon that a document gets renamed.
|
||||
This option makes the Kernel to check for missing dependencies,
|
||||
warning when something is missing. Works only if the Kernel
|
||||
is built from a git tree.
|
||||
|
||||
If unsure, select 'N'.
|
||||
If unsure, select 'N'.
|
||||
|
||||
config WARN_ABI_ERRORS
|
||||
bool "Warn if there are errors at ABI files"
|
||||
depends on COMPILE_TEST
|
||||
help
|
||||
The files under Documentation/ABI should follow what's
|
||||
described at Documentation/ABI/README. Yet, as they're manually
|
||||
written, it would be possible that some of those files would
|
||||
have errors that would break them for being parsed by
|
||||
scripts/get_abi.pl. Add a check to verify them.
|
||||
The files under Documentation/ABI should follow what's
|
||||
described at Documentation/ABI/README. Yet, as they're manually
|
||||
written, it would be possible that some of those files would
|
||||
have errors that would break them for being parsed by
|
||||
scripts/get_abi.pl. Add a check to verify them.
|
||||
|
||||
If unsure, select 'N'.
|
||||
If unsure, select 'N'.
|
||||
|
||||
@ -125,14 +125,14 @@ Following piece of code illustrates the usage of the SR-IOV API.
|
||||
...
|
||||
}
|
||||
|
||||
static int dev_suspend(struct pci_dev *dev, pm_message_t state)
|
||||
static int dev_suspend(struct device *dev)
|
||||
{
|
||||
...
|
||||
|
||||
return 0;
|
||||
}
|
||||
|
||||
static int dev_resume(struct pci_dev *dev)
|
||||
static int dev_resume(struct device *dev)
|
||||
{
|
||||
...
|
||||
|
||||
@ -165,8 +165,7 @@ Following piece of code illustrates the usage of the SR-IOV API.
|
||||
.id_table = dev_id_table,
|
||||
.probe = dev_probe,
|
||||
.remove = dev_remove,
|
||||
.suspend = dev_suspend,
|
||||
.resume = dev_resume,
|
||||
.driver.pm = &dev_pm_ops,
|
||||
.shutdown = dev_shutdown,
|
||||
.sriov_configure = dev_sriov_configure,
|
||||
};
|
||||
|
||||
@ -125,7 +125,7 @@ implementation of that functionality. To support the historical interface of
|
||||
mmap() through files in /proc/bus/pci, platforms may also set HAVE_PCI_MMAP.
|
||||
|
||||
Alternatively, platforms which set HAVE_PCI_MMAP may provide their own
|
||||
implementation of pci_mmap_page_range() instead of defining
|
||||
implementation of pci_mmap_resource_range() instead of defining
|
||||
ARCH_GENERIC_PCI_MMAP_RESOURCE.
|
||||
|
||||
Platforms which support write-combining maps of PCI resources must define
|
||||
|
||||
@ -1844,10 +1844,10 @@ that meets this requirement.
|
||||
|
||||
Furthermore, NMI handlers can be interrupted by what appear to RCU to be
|
||||
normal interrupts. One way that this can happen is for code that
|
||||
directly invokes rcu_irq_enter() and rcu_irq_exit() to be called
|
||||
directly invokes ct_irq_enter() and ct_irq_exit() to be called
|
||||
from an NMI handler. This astonishing fact of life prompted the current
|
||||
code structure, which has rcu_irq_enter() invoking
|
||||
rcu_nmi_enter() and rcu_irq_exit() invoking rcu_nmi_exit().
|
||||
code structure, which has ct_irq_enter() invoking
|
||||
ct_nmi_enter() and ct_irq_exit() invoking ct_nmi_exit().
|
||||
And yes, I also learned of this requirement the hard way.
|
||||
|
||||
Loadable Modules
|
||||
@ -2195,7 +2195,7 @@ scheduling-clock interrupt be enabled when RCU needs it to be:
|
||||
sections, and RCU believes this CPU to be idle, no problem. This
|
||||
sort of thing is used by some architectures for light-weight
|
||||
exception handlers, which can then avoid the overhead of
|
||||
rcu_irq_enter() and rcu_irq_exit() at exception entry and
|
||||
ct_irq_enter() and ct_irq_exit() at exception entry and
|
||||
exit, respectively. Some go further and avoid the entireties of
|
||||
irq_enter() and irq_exit().
|
||||
Just make very sure you are running some of your tests with
|
||||
@ -2226,7 +2226,7 @@ scheduling-clock interrupt be enabled when RCU needs it to be:
|
||||
+-----------------------------------------------------------------------+
|
||||
| **Answer**: |
|
||||
+-----------------------------------------------------------------------+
|
||||
| One approach is to do ``rcu_irq_exit();rcu_irq_enter();`` every so |
|
||||
| One approach is to do ``ct_irq_exit();ct_irq_enter();`` every so |
|
||||
| often. But given that long-running interrupt handlers can cause other |
|
||||
| problems, not least for response time, shouldn't you work to keep |
|
||||
| your interrupt handler's runtime within reasonable bounds? |
|
||||
|
||||
@ -97,12 +97,12 @@ warnings:
|
||||
which will include additional debugging information.
|
||||
|
||||
- A low-level kernel issue that either fails to invoke one of the
|
||||
variants of rcu_user_enter(), rcu_user_exit(), rcu_idle_enter(),
|
||||
rcu_idle_exit(), rcu_irq_enter(), or rcu_irq_exit() on the one
|
||||
variants of rcu_eqs_enter(true), rcu_eqs_exit(true), ct_idle_enter(),
|
||||
ct_idle_exit(), ct_irq_enter(), or ct_irq_exit() on the one
|
||||
hand, or that invokes one of them too many times on the other.
|
||||
Historically, the most frequent issue has been an omission
|
||||
of either irq_enter() or irq_exit(), which in turn invoke
|
||||
rcu_irq_enter() or rcu_irq_exit(), respectively. Building your
|
||||
ct_irq_enter() or ct_irq_exit(), respectively. Building your
|
||||
kernel with CONFIG_RCU_EQS_DEBUG=y can help track down these types
|
||||
of issues, which sometimes arise in architecture-specific code.
|
||||
|
||||
|
||||
@ -97,7 +97,7 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
|
||||
=============
|
||||
|
||||
Page Cache is charged at
|
||||
- add_to_page_cache_locked().
|
||||
- filemap_add_folio().
|
||||
|
||||
The logic is very clear. (About migration, see below)
|
||||
|
||||
|
||||
@ -184,6 +184,14 @@ cgroup v2 currently supports the following mount options.
|
||||
ignored on non-init namespace mounts. Please refer to the
|
||||
Delegation section for details.
|
||||
|
||||
favordynmods
|
||||
Reduce the latencies of dynamic cgroup modifications such as
|
||||
task migrations and controller on/offs at the cost of making
|
||||
hot path operations such as forks and exits more expensive.
|
||||
The static usage pattern of creating a cgroup, enabling
|
||||
controllers, and then seeding it with CLONE_INTO_CGROUP is
|
||||
not affected by this option.
|
||||
|
||||
memory_localevents
|
||||
Only populate memory.events with data for the current cgroup,
|
||||
and not any subtrees. This is legacy behaviour, the default
|
||||
|
||||
@ -20,6 +20,7 @@ Constructor parameters:
|
||||
size)
|
||||
5. the number of optional parameters (the parameters with an argument
|
||||
count as two)
|
||||
|
||||
start_sector n (default: 0)
|
||||
offset from the start of cache device in 512-byte sectors
|
||||
high_watermark n (default: 50)
|
||||
@ -74,20 +75,21 @@ Constructor parameters:
|
||||
the origin volume in the last n milliseconds
|
||||
|
||||
Status:
|
||||
|
||||
1. error indicator - 0 if there was no error, otherwise error number
|
||||
2. the number of blocks
|
||||
3. the number of free blocks
|
||||
4. the number of blocks under writeback
|
||||
5. the number of read requests
|
||||
6. the number of read requests that hit the cache
|
||||
7. the number of write requests
|
||||
8. the number of write requests that hit uncommitted block
|
||||
9. the number of write requests that hit committed block
|
||||
10. the number of write requests that bypass the cache
|
||||
11. the number of write requests that are allocated in the cache
|
||||
5. the number of read blocks
|
||||
6. the number of read blocks that hit the cache
|
||||
7. the number of write blocks
|
||||
8. the number of write blocks that hit uncommitted block
|
||||
9. the number of write blocks that hit committed block
|
||||
10. the number of write blocks that bypass the cache
|
||||
11. the number of write blocks that are allocated in the cache
|
||||
12. the number of write requests that are blocked on the freelist
|
||||
13. the number of flush requests
|
||||
14. the number of discard requests
|
||||
14. the number of discarded blocks
|
||||
|
||||
Messages:
|
||||
flush
|
||||
|
||||
@ -7,10 +7,9 @@ This list is the Linux Device List, the official registry of allocated
|
||||
device numbers and ``/dev`` directory nodes for the Linux operating
|
||||
system.
|
||||
|
||||
The LaTeX version of this document is no longer maintained, nor is
|
||||
the document that used to reside at lanana.org. This version in the
|
||||
mainline Linux kernel is the master document. Updates shall be sent
|
||||
as patches to the kernel maintainers (see the
|
||||
The version of this document at lanana.org is no longer maintained. This
|
||||
version in the mainline Linux kernel is the master document. Updates
|
||||
shall be sent as patches to the kernel maintainers (see the
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` document).
|
||||
Specifically explore the sections titled "CHAR and MISC DRIVERS", and
|
||||
"BLOCK LAYER" in the MAINTAINERS file to find the right maintainers
|
||||
|
||||
@ -7,10 +7,10 @@ as a PE/COFF image, thereby convincing EFI firmware loaders to load
|
||||
it as an EFI executable. The code that modifies the bzImage header,
|
||||
along with the EFI-specific entry point that the firmware loader
|
||||
jumps to are collectively known as the "EFI boot stub", and live in
|
||||
arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
|
||||
arch/x86/boot/header.S and drivers/firmware/efi/libstub/x86-stub.c,
|
||||
respectively. For ARM the EFI stub is implemented in
|
||||
arch/arm/boot/compressed/efi-header.S and
|
||||
arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
|
||||
drivers/firmware/efi/libstub/arm32-stub.c. EFI stub code that is shared
|
||||
between architectures is in drivers/firmware/efi/libstub.
|
||||
|
||||
For arm64, there is no compressed kernel support, so the Image itself
|
||||
|
||||
@ -400,6 +400,12 @@
|
||||
arm64.nomte [ARM64] Unconditionally disable Memory Tagging Extension
|
||||
support
|
||||
|
||||
arm64.nosve [ARM64] Unconditionally disable Scalable Vector
|
||||
Extension support
|
||||
|
||||
arm64.nosme [ARM64] Unconditionally disable Scalable Matrix
|
||||
Extension support
|
||||
|
||||
ataflop= [HW,M68k]
|
||||
|
||||
atarimouse= [HW,MOUSE] Atari Mouse
|
||||
@ -550,7 +556,7 @@
|
||||
nosocket -- Disable socket memory accounting.
|
||||
nokmem -- Disable kernel memory accounting.
|
||||
|
||||
checkreqprot [SELINUX] Set initial checkreqprot flag value.
|
||||
checkreqprot= [SELINUX] Set initial checkreqprot flag value.
|
||||
Format: { "0" | "1" }
|
||||
See security/selinux/Kconfig help text.
|
||||
0 -- check protection applied by kernel (includes
|
||||
@ -1439,7 +1445,7 @@
|
||||
(in particular on some ATI chipsets).
|
||||
The kernel tries to set a reasonable default.
|
||||
|
||||
enforcing [SELINUX] Set initial enforcing status.
|
||||
enforcing= [SELINUX] Set initial enforcing status.
|
||||
Format: {"0" | "1"}
|
||||
See security/selinux/Kconfig help text.
|
||||
0 -- permissive (log only, no denials).
|
||||
@ -3111,7 +3117,7 @@
|
||||
mem_encrypt=on: Activate SME
|
||||
mem_encrypt=off: Do not activate SME
|
||||
|
||||
Refer to Documentation/virt/kvm/amd-memory-encryption.rst
|
||||
Refer to Documentation/virt/kvm/x86/amd-memory-encryption.rst
|
||||
for details on when memory encryption can be activated.
|
||||
|
||||
mem_sleep_default= [SUSPEND] Default system suspend mode:
|
||||
@ -3169,7 +3175,7 @@
|
||||
improves system performance, but it may also
|
||||
expose users to several CPU vulnerabilities.
|
||||
Equivalent to: nopti [X86,PPC]
|
||||
kpti=0 [ARM64]
|
||||
if nokaslr then kpti=0 [ARM64]
|
||||
nospectre_v1 [X86,PPC]
|
||||
nobp=0 [S390]
|
||||
nospectre_v2 [X86,PPC,S390,ARM64]
|
||||
@ -3669,6 +3675,9 @@
|
||||
just as if they had also been called out in the
|
||||
rcu_nocbs= boot parameter.
|
||||
|
||||
Note that this argument takes precedence over
|
||||
the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option.
|
||||
|
||||
noiotrap [SH] Disables trapped I/O port accesses.
|
||||
|
||||
noirqdebug [X86-32] Disables the code which attempts to detect and
|
||||
@ -3743,11 +3752,6 @@
|
||||
noreplace-smp [X86-32,SMP] Don't replace SMP instructions
|
||||
with UP alternatives
|
||||
|
||||
nordrand [X86] Disable kernel use of the RDRAND and
|
||||
RDSEED instructions even if they are supported
|
||||
by the processor. RDRAND and RDSEED are still
|
||||
available to user space applications.
|
||||
|
||||
noresume [SWSUSP] Disables resume and restores original swap
|
||||
space.
|
||||
|
||||
@ -4567,6 +4571,9 @@
|
||||
no-callback mode from boot but the mode may be
|
||||
toggled at runtime via cpusets.
|
||||
|
||||
Note that this argument takes precedence over
|
||||
the CONFIG_RCU_NOCB_CPU_DEFAULT_ALL option.
|
||||
|
||||
rcu_nocb_poll [KNL]
|
||||
Rather than requiring that offloaded CPUs
|
||||
(specified by rcu_nocbs= above) explicitly
|
||||
@ -4676,6 +4683,34 @@
|
||||
When RCU_NOCB_CPU is set, also adjust the
|
||||
priority of NOCB callback kthreads.
|
||||
|
||||
rcutree.rcu_divisor= [KNL]
|
||||
Set the shift-right count to use to compute
|
||||
the callback-invocation batch limit bl from
|
||||
the number of callbacks queued on this CPU.
|
||||
The result will be bounded below by the value of
|
||||
the rcutree.blimit kernel parameter. Every bl
|
||||
callbacks, the softirq handler will exit in
|
||||
order to allow the CPU to do other work.
|
||||
|
||||
Please note that this callback-invocation batch
|
||||
limit applies only to non-offloaded callback
|
||||
invocation. Offloaded callbacks are instead
|
||||
invoked in the context of an rcuoc kthread, which
|
||||
scheduler will preempt as it does any other task.
|
||||
|
||||
rcutree.nocb_nobypass_lim_per_jiffy= [KNL]
|
||||
On callback-offloaded (rcu_nocbs) CPUs,
|
||||
RCU reduces the lock contention that would
|
||||
otherwise be caused by callback floods through
|
||||
use of the ->nocb_bypass list. However, in the
|
||||
common non-flooded case, RCU queues directly to
|
||||
the main ->cblist in order to avoid the extra
|
||||
overhead of the ->nocb_bypass list and its lock.
|
||||
But if there are too many callbacks queued during
|
||||
a single jiffy, RCU pre-queues the callbacks into
|
||||
the ->nocb_bypass queue. The definition of "too
|
||||
many" is supplied by this kernel boot parameter.
|
||||
|
||||
rcutree.rcu_nocb_gp_stride= [KNL]
|
||||
Set the number of NOCB callback kthreads in
|
||||
each group, which defaults to the square root
|
||||
|
||||
136
Documentation/admin-guide/perf/hns3-pmu.rst
Normal file
136
Documentation/admin-guide/perf/hns3-pmu.rst
Normal file
@ -0,0 +1,136 @@
|
||||
======================================
|
||||
HNS3 Performance Monitoring Unit (PMU)
|
||||
======================================
|
||||
|
||||
HNS3(HiSilicon network system 3) Performance Monitoring Unit (PMU) is an
|
||||
End Point device to collect performance statistics of HiSilicon SoC NIC.
|
||||
On Hip09, each SICL(Super I/O cluster) has one PMU device.
|
||||
|
||||
HNS3 PMU supports collection of performance statistics such as bandwidth,
|
||||
latency, packet rate and interrupt rate.
|
||||
|
||||
Each HNS3 PMU supports 8 hardware events.
|
||||
|
||||
HNS3 PMU driver
|
||||
===============
|
||||
|
||||
The HNS3 PMU driver registers a perf PMU with the name of its sicl id.::
|
||||
|
||||
/sys/devices/hns3_pmu_sicl_<sicl_id>
|
||||
|
||||
PMU driver provides description of available events, filter modes, format,
|
||||
identifier and cpumask in sysfs.
|
||||
|
||||
The "events" directory describes the event code of all supported events
|
||||
shown in perf list.
|
||||
|
||||
The "filtermode" directory describes the supported filter modes of each
|
||||
event.
|
||||
|
||||
The "format" directory describes all formats of the config (events) and
|
||||
config1 (filter options) fields of the perf_event_attr structure.
|
||||
|
||||
The "identifier" file shows version of PMU hardware device.
|
||||
|
||||
The "bdf_min" and "bdf_max" files show the supported bdf range of each
|
||||
pmu device.
|
||||
|
||||
The "hw_clk_freq" file shows the hardware clock frequency of each pmu
|
||||
device.
|
||||
|
||||
Example usage of checking event code and subevent code::
|
||||
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
|
||||
config=0x00204
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
|
||||
config=0x10204
|
||||
|
||||
Each performance statistic has a pair of events to get two values to
|
||||
calculate real performance data in userspace.
|
||||
|
||||
The bits 0~15 of config (here 0x0204) are the true hardware event code. If
|
||||
two events have same value of bits 0~15 of config, that means they are
|
||||
event pair. And the bit 16 of config indicates getting counter 0 or
|
||||
counter 1 of hardware event.
|
||||
|
||||
After getting two values of event pair in usersapce, the formula of
|
||||
computation to calculate real performance data is:::
|
||||
|
||||
counter 0 / counter 1
|
||||
|
||||
Example usage of checking supported filter mode::
|
||||
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
|
||||
filter mode supported: global/port/port-tc/func/func-queue/
|
||||
|
||||
Example usage of perf::
|
||||
|
||||
$# perf list
|
||||
hns3_pmu_sicl_0/bw_ssu_rpu_byte_num/ [kernel PMU event]
|
||||
hns3_pmu_sicl_0/bw_ssu_rpu_time/ [kernel PMU event]
|
||||
------------------------------------------
|
||||
|
||||
$# perf stat -g -e hns3_pmu_sicl_0/bw_ssu_rpu_byte_num,global=1/ -e hns3_pmu_sicl_0/bw_ssu_rpu_time,global=1/ -I 1000
|
||||
or
|
||||
$# perf stat -g -e hns3_pmu_sicl_0/config=0x00002,global=1/ -e hns3_pmu_sicl_0/config=0x10002,global=1/ -I 1000
|
||||
|
||||
|
||||
Filter modes
|
||||
--------------
|
||||
|
||||
1. global mode
|
||||
PMU collect performance statistics for all HNS3 PCIe functions of IO DIE.
|
||||
Set the "global" filter option to 1 will enable this mode.
|
||||
Example usage of perf::
|
||||
|
||||
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,global=1/ -I 1000
|
||||
|
||||
2. port mode
|
||||
PMU collect performance statistic of one whole physical port. The port id
|
||||
is same as mac id. The "tc" filter option must be set to 0xF in this mode,
|
||||
here tc stands for traffic class.
|
||||
|
||||
Example usage of perf::
|
||||
|
||||
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,port=0,tc=0xF/ -I 1000
|
||||
|
||||
3. port-tc mode
|
||||
PMU collect performance statistic of one tc of physical port. The port id
|
||||
is same as mac id. The "tc" filter option must be set to 0 ~ 7 in this
|
||||
mode.
|
||||
Example usage of perf::
|
||||
|
||||
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,port=0,tc=0/ -I 1000
|
||||
|
||||
4. func mode
|
||||
PMU collect performance statistic of one PF/VF. The function id is BDF of
|
||||
PF/VF, its conversion formula::
|
||||
|
||||
func = (bus << 8) + (device << 3) + (function)
|
||||
|
||||
for example:
|
||||
BDF func
|
||||
35:00.0 0x3500
|
||||
35:00.1 0x3501
|
||||
35:01.0 0x3508
|
||||
|
||||
In this mode, the "queue" filter option must be set to 0xFFFF.
|
||||
Example usage of perf::
|
||||
|
||||
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,bdf=0x3500,queue=0xFFFF/ -I 1000
|
||||
|
||||
5. func-queue mode
|
||||
PMU collect performance statistic of one queue of PF/VF. The function id
|
||||
is BDF of PF/VF, the "queue" filter option must be set to the exact queue
|
||||
id of function.
|
||||
Example usage of perf::
|
||||
|
||||
$# perf stat -a -e hns3_pmu_sicl_0/config=0x1020F,bdf=0x3500,queue=0/ -I 1000
|
||||
|
||||
6. func-intr mode
|
||||
PMU collect performance statistic of one interrupt of PF/VF. The function
|
||||
id is BDF of PF/VF, the "intr" filter option must be set to the exact
|
||||
interrupt id of function.
|
||||
Example usage of perf::
|
||||
|
||||
$# perf stat -a -e hns3_pmu_sicl_0/config=0x00301,bdf=0x3500,intr=0/ -I 1000
|
||||
@ -9,6 +9,7 @@ Performance monitor support
|
||||
|
||||
hisi-pmu
|
||||
hisi-pcie-pmu
|
||||
hns3-pmu
|
||||
imx-ddr
|
||||
qcom_l2_pmu
|
||||
qcom_l3_pmu
|
||||
|
||||
@ -612,8 +612,8 @@ the ``menu`` governor to be used on the systems that use the ``ladder`` governor
|
||||
by default this way, for example.
|
||||
|
||||
The other kernel command line parameters controlling CPU idle time management
|
||||
described below are only relevant for the *x86* architecture and some of
|
||||
them affect Intel processors only.
|
||||
described below are only relevant for the *x86* architecture and references
|
||||
to ``intel_idle`` affect Intel processors only.
|
||||
|
||||
The *x86* architecture support code recognizes three kernel command line
|
||||
options related to CPU idle time management: ``idle=poll``, ``idle=halt``,
|
||||
@ -635,10 +635,13 @@ idle, so it very well may hurt single-thread computations performance as well as
|
||||
energy-efficiency. Thus using it for performance reasons may not be a good idea
|
||||
at all.]
|
||||
|
||||
The ``idle=nomwait`` option disables the ``intel_idle`` driver and causes
|
||||
``acpi_idle`` to be used (as long as all of the information needed by it is
|
||||
there in the system's ACPI tables), but it is not allowed to use the
|
||||
``MWAIT`` instruction of the CPUs to ask the hardware to enter idle states.
|
||||
The ``idle=nomwait`` option prevents the use of ``MWAIT`` instruction of
|
||||
the CPU to enter idle states. When this option is used, the ``acpi_idle``
|
||||
driver will use the ``HLT`` instruction instead of ``MWAIT``. On systems
|
||||
running Intel processors, this option disables the ``intel_idle`` driver
|
||||
and forces the use of the ``acpi_idle`` driver instead. Note that in either
|
||||
case, ``acpi_idle`` driver will function only if all the information needed
|
||||
by it is in the system's ACPI tables.
|
||||
|
||||
In addition to the architecture-level kernel command line options affecting CPU
|
||||
idle time management, there are parameters affecting individual ``CPUIdle``
|
||||
|
||||
@ -38,8 +38,8 @@ acct
|
||||
|
||||
If BSD-style process accounting is enabled these values control
|
||||
its behaviour. If free space on filesystem where the log lives
|
||||
goes below ``lowwater``% accounting suspends. If free space gets
|
||||
above ``highwater``% accounting resumes. ``frequency`` determines
|
||||
goes below ``lowwater``\ % accounting suspends. If free space gets
|
||||
above ``highwater``\ % accounting resumes. ``frequency`` determines
|
||||
how often do we check the amount of free space (value is in
|
||||
seconds). Default:
|
||||
|
||||
|
||||
@ -100,6 +100,7 @@ Bit Log Number Reason that got the kernel tainted
|
||||
15 _/K 32768 kernel has been live patched
|
||||
16 _/X 65536 auxiliary taint, defined for and used by distros
|
||||
17 _/T 131072 kernel was built with the struct randomization plugin
|
||||
18 _/N 262144 an in-kernel test has been run
|
||||
=== === ====== ========================================================
|
||||
|
||||
Note: The character ``_`` is representing a blank in this table to make reading
|
||||
|
||||
69
Documentation/arm/google/chromebook-boot-flow.rst
Normal file
69
Documentation/arm/google/chromebook-boot-flow.rst
Normal file
@ -0,0 +1,69 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======================================
|
||||
Chromebook Boot Flow
|
||||
======================================
|
||||
|
||||
Most recent Chromebooks that use device tree are using the opensource
|
||||
depthcharge_ bootloader. Depthcharge_ expects the OS to be packaged as a `FIT
|
||||
Image`_ which contains an OS image as well as a collection of device trees. It
|
||||
is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
|
||||
provide it to the OS.
|
||||
|
||||
The scheme that depthcharge_ uses to pick the device tree takes into account
|
||||
three variables:
|
||||
|
||||
- Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
|
||||
- Board revision number, determined at runtime (perhaps by reading GPIO
|
||||
strappings, perhaps via some other method). This is $(REV) below.
|
||||
- SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
|
||||
|
||||
For recent Chromebooks, depthcharge_ creates a match list that looks like this:
|
||||
|
||||
- google,$(BOARD)-rev$(REV)-sku$(SKU)
|
||||
- google,$(BOARD)-rev$(REV)
|
||||
- google,$(BOARD)-sku$(SKU)
|
||||
- google,$(BOARD)
|
||||
|
||||
Note that some older Chromebooks use a slightly different list that may
|
||||
not include SKU matching or may prioritize SKU/rev differently.
|
||||
|
||||
Note that for some boards there may be extra board-specific logic to inject
|
||||
extra compatibles into the list, but this is uncommon.
|
||||
|
||||
Depthcharge_ will look through all device trees in the `FIT Image`_ trying to
|
||||
find one that matches the most specific compatible. It will then look
|
||||
through all device trees in the `FIT Image`_ trying to find the one that
|
||||
matches the *second most* specific compatible, etc.
|
||||
|
||||
When searching for a device tree, depthcharge_ doesn't care where the
|
||||
compatible string falls within a device tree's root compatible string array.
|
||||
As an example, if we're on board "lazor", rev 4, SKU 0 and we have two device
|
||||
trees:
|
||||
|
||||
- "google,lazor-rev5-sku0", "google,lazor-rev4-sku0", "qcom,sc7180"
|
||||
- "google,lazor", "qcom,sc7180"
|
||||
|
||||
Then depthcharge_ will pick the first device tree even though
|
||||
"google,lazor-rev4-sku0" was the second compatible listed in that device tree.
|
||||
This is because it is a more specific compatible than "google,lazor".
|
||||
|
||||
It should be noted that depthcharge_ does not have any smarts to try to
|
||||
match board or SKU revisions that are "close by". That is to say that
|
||||
if depthcharge_ knows it's on "rev4" of a board but there is no "rev4"
|
||||
device tree then depthcharge_ *won't* look for a "rev3" device tree.
|
||||
|
||||
In general when any significant changes are made to a board the board
|
||||
revision number is increased even if none of those changes need to
|
||||
be reflected in the device tree. Thus it's fairly common to see device
|
||||
trees with multiple revisions.
|
||||
|
||||
It should be noted that, taking into account the above system that
|
||||
depthcharge_ has, the most flexibility is achieved if the device tree
|
||||
supporting the newest revision(s) of a board omits the "-rev{REV}"
|
||||
compatible strings. When this is done then if you get a new board
|
||||
revision and try to run old software on it then we'll at pick the
|
||||
newest device tree we know about.
|
||||
|
||||
.. _depthcharge: https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/platform/depthcharge/
|
||||
.. _`FIT Image`: https://doc.coreboot.org/lib/payloads/fit.html
|
||||
@ -31,6 +31,8 @@ SoC-specific documents
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
google/chromebook-boot-flow
|
||||
|
||||
ixp4xx
|
||||
|
||||
marvell
|
||||
|
||||
@ -171,96 +171,73 @@ HWCAP_PACG
|
||||
Documentation/arm64/pointer-authentication.rst.
|
||||
|
||||
HWCAP2_DCPODP
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
|
||||
|
||||
HWCAP2_SVE2
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
|
||||
|
||||
HWCAP2_SVEAES
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
|
||||
|
||||
HWCAP2_SVEPMULL
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0010.
|
||||
|
||||
HWCAP2_SVEBITPERM
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.BitPerm == 0b0001.
|
||||
|
||||
HWCAP2_SVESHA3
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.SHA3 == 0b0001.
|
||||
|
||||
HWCAP2_SVESM4
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.SM4 == 0b0001.
|
||||
|
||||
HWCAP2_FLAGM2
|
||||
|
||||
Functionality implied by ID_AA64ISAR0_EL1.TS == 0b0010.
|
||||
|
||||
HWCAP2_FRINT
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.FRINTTS == 0b0001.
|
||||
|
||||
HWCAP2_SVEI8MM
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.I8MM == 0b0001.
|
||||
|
||||
HWCAP2_SVEF32MM
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.F32MM == 0b0001.
|
||||
|
||||
HWCAP2_SVEF64MM
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.F64MM == 0b0001.
|
||||
|
||||
HWCAP2_SVEBF16
|
||||
|
||||
Functionality implied by ID_AA64ZFR0_EL1.BF16 == 0b0001.
|
||||
|
||||
HWCAP2_I8MM
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.I8MM == 0b0001.
|
||||
|
||||
HWCAP2_BF16
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0001.
|
||||
|
||||
HWCAP2_DGH
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.DGH == 0b0001.
|
||||
|
||||
HWCAP2_RNG
|
||||
|
||||
Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
|
||||
|
||||
HWCAP2_BTI
|
||||
|
||||
Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
|
||||
|
||||
HWCAP2_MTE
|
||||
|
||||
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
|
||||
by Documentation/arm64/memory-tagging-extension.rst.
|
||||
|
||||
HWCAP2_ECV
|
||||
|
||||
Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
|
||||
|
||||
HWCAP2_AFP
|
||||
|
||||
Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
|
||||
|
||||
HWCAP2_RPRES
|
||||
|
||||
Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
|
||||
|
||||
HWCAP2_MTE3
|
||||
|
||||
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described
|
||||
by Documentation/arm64/memory-tagging-extension.rst.
|
||||
|
||||
@ -301,6 +278,10 @@ HWCAP2_WFXT
|
||||
|
||||
Functionality implied by ID_AA64ISAR2_EL1.WFXT == 0b0010.
|
||||
|
||||
HWCAP2_EBF16
|
||||
|
||||
Functionality implied by ID_AA64ISAR1_EL1.BF16 == 0b0010.
|
||||
|
||||
4. Unused AT_HWCAP bits
|
||||
-----------------------
|
||||
|
||||
|
||||
@ -33,9 +33,8 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
|
||||
0000000000000000 0000ffffffffffff 256TB user
|
||||
ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map
|
||||
[ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region]
|
||||
ffff800000000000 ffff800007ffffff 128MB bpf jit region
|
||||
ffff800008000000 ffff80000fffffff 128MB modules
|
||||
ffff800010000000 fffffbffefffffff 124TB vmalloc
|
||||
ffff800000000000 ffff800007ffffff 128MB modules
|
||||
ffff800008000000 fffffbffefffffff 124TB vmalloc
|
||||
fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
|
||||
fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
|
||||
fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
|
||||
@ -51,9 +50,8 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support):
|
||||
0000000000000000 000fffffffffffff 4PB user
|
||||
fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map
|
||||
[fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region]
|
||||
ffff800000000000 ffff800007ffffff 128MB bpf jit region
|
||||
ffff800008000000 ffff80000fffffff 128MB modules
|
||||
ffff800010000000 fffffbffefffffff 124TB vmalloc
|
||||
ffff800000000000 ffff800007ffffff 128MB modules
|
||||
ffff800008000000 fffffbffefffffff 124TB vmalloc
|
||||
fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down)
|
||||
fffffbfffe000000 fffffbfffe7fffff 8MB [guard region]
|
||||
fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space
|
||||
|
||||
@ -82,10 +82,14 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A57 | #1319537 | ARM64_ERRATUM_1319367 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A57 | #1742098 | ARM64_ERRATUM_1742098 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A72 | #853709 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A72 | #1319367 | ARM64_ERRATUM_1319367 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A72 | #1655431 | ARM64_ERRATUM_1742098 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A73 | #858921 | ARM64_ERRATUM_858921 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A76 | #1188873,1418040| ARM64_ERRATUM_1418040 |
|
||||
@ -102,6 +106,8 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2441009 | ARM64_ERRATUM_2441009 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
|
||||
|
||||
@ -17,6 +17,9 @@ solution to the problem to avoid everybody inventing their own. The IDR
|
||||
provides the ability to map an ID to a pointer, while the IDA provides
|
||||
only ID allocation, and as a result is much more memory-efficient.
|
||||
|
||||
The IDR interface is deprecated; please use the :doc:`XArray <xarray>`
|
||||
instead.
|
||||
|
||||
IDR usage
|
||||
=========
|
||||
|
||||
|
||||
@ -4,31 +4,29 @@
|
||||
Memory Protection Keys
|
||||
======================
|
||||
|
||||
Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature
|
||||
which is found on Intel's Skylake (and later) "Scalable Processor"
|
||||
Server CPUs. It will be available in future non-server Intel parts
|
||||
and future AMD processors.
|
||||
Memory Protection Keys provide a mechanism for enforcing page-based
|
||||
protections, but without requiring modification of the page tables when an
|
||||
application changes protection domains.
|
||||
|
||||
For anyone wishing to test or use this feature, it is available in
|
||||
Amazon's EC2 C5 instances and is known to work there using an Ubuntu
|
||||
17.04 image.
|
||||
Pkeys Userspace (PKU) is a feature which can be found on:
|
||||
* Intel server CPUs, Skylake and later
|
||||
* Intel client CPUs, Tiger Lake (11th Gen Core) and later
|
||||
* Future AMD CPUs
|
||||
|
||||
Memory Protection Keys provides a mechanism for enforcing page-based
|
||||
protections, but without requiring modification of the page tables
|
||||
when an application changes protection domains. It works by
|
||||
dedicating 4 previously ignored bits in each page table entry to a
|
||||
"protection key", giving 16 possible keys.
|
||||
Pkeys work by dedicating 4 previously Reserved bits in each page table entry to
|
||||
a "protection key", giving 16 possible keys.
|
||||
|
||||
There is also a new user-accessible register (PKRU) with two separate
|
||||
bits (Access Disable and Write Disable) for each key. Being a CPU
|
||||
register, PKRU is inherently thread-local, potentially giving each
|
||||
Protections for each key are defined with a per-CPU user-accessible register
|
||||
(PKRU). Each of these is a 32-bit register storing two bits (Access Disable
|
||||
and Write Disable) for each of 16 keys.
|
||||
|
||||
Being a CPU register, PKRU is inherently thread-local, potentially giving each
|
||||
thread a different set of protections from every other thread.
|
||||
|
||||
There are two new instructions (RDPKRU/WRPKRU) for reading and writing
|
||||
to the new register. The feature is only available in 64-bit mode,
|
||||
even though there is theoretically space in the PAE PTEs. These
|
||||
permissions are enforced on data access only and have no effect on
|
||||
instruction fetches.
|
||||
There are two instructions (RDPKRU/WRPKRU) for reading and writing to the
|
||||
register. The feature is only available in 64-bit mode, even though there is
|
||||
theoretically space in the PAE PTEs. These permissions are enforced on data
|
||||
access only and have no effect on instruction fetches.
|
||||
|
||||
Syscalls
|
||||
========
|
||||
|
||||
@ -66,7 +66,7 @@ The wiki documentation always refers to the linux-next version of the script.
|
||||
|
||||
For Semantic Patch Language(SmPL) grammar documentation refer to:
|
||||
|
||||
http://coccinelle.lip6.fr/documentation.php
|
||||
https://coccinelle.gitlabpages.inria.fr/website/docs/main_grammar.html
|
||||
|
||||
Using Coccinelle on the Linux kernel
|
||||
------------------------------------
|
||||
|
||||
@ -208,6 +208,14 @@ In general, the rules for selftests are
|
||||
Contributing new tests (details)
|
||||
================================
|
||||
|
||||
* In your Makefile, use facilities from lib.mk by including it instead of
|
||||
reinventing the wheel. Specify flags and binaries generation flags on
|
||||
need basis before including lib.mk. ::
|
||||
|
||||
CFLAGS = $(KHDR_INCLUDES)
|
||||
TEST_GEN_PROGS := close_range_test
|
||||
include ../lib.mk
|
||||
|
||||
* Use TEST_GEN_XXX if such binaries or files are generated during
|
||||
compiling.
|
||||
|
||||
@ -230,13 +238,30 @@ Contributing new tests (details)
|
||||
* First use the headers inside the kernel source and/or git repo, and then the
|
||||
system headers. Headers for the kernel release as opposed to headers
|
||||
installed by the distro on the system should be the primary focus to be able
|
||||
to find regressions.
|
||||
to find regressions. Use KHDR_INCLUDES in Makefile to include headers from
|
||||
the kernel source.
|
||||
|
||||
* If a test needs specific kernel config options enabled, add a config file in
|
||||
the test directory to enable them.
|
||||
|
||||
e.g: tools/testing/selftests/android/config
|
||||
|
||||
* Create a .gitignore file inside test directory and add all generated objects
|
||||
in it.
|
||||
|
||||
* Add new test name in TARGETS in selftests/Makefile::
|
||||
|
||||
TARGETS += android
|
||||
|
||||
* All changes should pass::
|
||||
|
||||
kselftest-{all,install,clean,gen_tar}
|
||||
kselftest-{all,install,clean,gen_tar} O=abo_path
|
||||
kselftest-{all,install,clean,gen_tar} O=rel_path
|
||||
make -C tools/testing/selftests {all,install,clean,gen_tar}
|
||||
make -C tools/testing/selftests {all,install,clean,gen_tar} O=abs_path
|
||||
make -C tools/testing/selftests {all,install,clean,gen_tar} O=rel_path
|
||||
|
||||
Test Module
|
||||
===========
|
||||
|
||||
@ -250,6 +275,14 @@ assist writing kernel modules that are for use with kselftest:
|
||||
- ``tools/testing/selftests/kselftest_module.h``
|
||||
- ``tools/testing/selftests/kselftest/module.sh``
|
||||
|
||||
Note that test modules should taint the kernel with TAINT_TEST. This will
|
||||
happen automatically for modules which are in the ``tools/testing/``
|
||||
directory, or for modules which use the ``kselftest_module.h`` header above.
|
||||
Otherwise, you'll need to add ``MODULE_INFO(test, "Y")`` to your module
|
||||
source. selftests which do not load modules typically should not taint the
|
||||
kernel, but in cases where a non-test module is loaded, TEST_TAINT can be
|
||||
applied from userspace by writing to ``/proc/sys/kernel/tainted``.
|
||||
|
||||
How to use
|
||||
----------
|
||||
|
||||
@ -308,6 +341,7 @@ A bare bones test module might look like this:
|
||||
KSTM_MODULE_LOADERS(test_foo);
|
||||
MODULE_AUTHOR("John Developer <jd@fooman.org>");
|
||||
MODULE_LICENSE("GPL");
|
||||
MODULE_INFO(test, "Y");
|
||||
|
||||
Example test script
|
||||
-------------------
|
||||
|
||||
@ -192,6 +192,21 @@ via UML. To run tests on qemu, by default it requires two flags:
|
||||
if we have downloaded the microblaze toolchain from the 0-day
|
||||
website to a directory in our home directory called toolchains.
|
||||
|
||||
This means that for most architectures, running under qemu is as simple as:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
./tools/testing/kunit/kunit.py run --arch=x86_64
|
||||
|
||||
When cross-compiling, we'll likely need to specify a different toolchain, for
|
||||
example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
./tools/testing/kunit/kunit.py run \
|
||||
--arch=s390 \
|
||||
--cross_compile=s390x-linux-gnu-
|
||||
|
||||
If we want to run KUnit tests on an architecture not supported by
|
||||
the ``--arch`` flag, or want to run KUnit tests on qemu using a
|
||||
non-default configuration; then we can write our own``QemuConfig``.
|
||||
@ -214,14 +229,11 @@ as
|
||||
--jobs=12 \
|
||||
--qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py
|
||||
|
||||
To run existing KUnit tests on non-UML architectures, see:
|
||||
Documentation/dev-tools/kunit/non_uml.rst.
|
||||
|
||||
Command-Line Arguments
|
||||
======================
|
||||
|
||||
kunit_tool has a number of other command-line arguments which can
|
||||
be useful for our test environment. Below the most commonly used
|
||||
be useful for our test environment. Below are the most commonly used
|
||||
command line arguments:
|
||||
|
||||
- ``--help``: Lists all available options. To list common options,
|
||||
@ -245,3 +257,64 @@ command line arguments:
|
||||
added or modified. Instead, enable all tests
|
||||
which have satisfied dependencies by adding
|
||||
``CONFIG_KUNIT_ALL_TESTS=y`` to your ``.kunitconfig``.
|
||||
|
||||
- ``--kunitconfig``: Specifies the path or the directory of the ``.kunitconfig``
|
||||
file. For example:
|
||||
|
||||
- ``lib/kunit/.kunitconfig`` can be the path of the file.
|
||||
|
||||
- ``lib/kunit`` can be the directory in which the file is located.
|
||||
|
||||
This file is used to build and run with a predefined set of tests
|
||||
and their dependencies. For example, to run tests for a given subsystem.
|
||||
|
||||
- ``--kconfig_add``: Specifies additional configuration options to be
|
||||
appended to the ``.kunitconfig`` file. For example:
|
||||
|
||||
.. code-block::
|
||||
|
||||
./tools/testing/kunit/kunit.py run --kconfig_add CONFIG_KASAN=y
|
||||
|
||||
- ``--arch``: Runs tests on the specified architecture. The architecture
|
||||
argument is same as the Kbuild ARCH environment variable.
|
||||
For example, i386, x86_64, arm, um, etc. Non-UML architectures run on qemu.
|
||||
Default is `um`.
|
||||
|
||||
- ``--cross_compile``: Specifies the Kbuild toolchain. It passes the
|
||||
same argument as passed to the ``CROSS_COMPILE`` variable used by
|
||||
Kbuild. This will be the prefix for the toolchain
|
||||
binaries such as GCC. For example:
|
||||
|
||||
- ``sparc64-linux-gnu-`` if we have the sparc toolchain installed on
|
||||
our system.
|
||||
|
||||
- ``$HOME/toolchains/microblaze/gcc-9.2.0-nolibc/microblaze-linux/bin/microblaze-linux``
|
||||
if we have downloaded the microblaze toolchain from the 0-day
|
||||
website to a specified path in our home directory called toolchains.
|
||||
|
||||
- ``--qemu_config``: Specifies the path to a file containing a
|
||||
custom qemu architecture definition. This should be a python file
|
||||
containing a `QemuArchParams` object.
|
||||
|
||||
- ``--qemu_args``: Specifies additional qemu arguments, for example, ``-smp 8``.
|
||||
|
||||
- ``--jobs``: Specifies the number of jobs (commands) to run simultaneously.
|
||||
By default, this is set to the number of cores on your system.
|
||||
|
||||
- ``--timeout``: Specifies the maximum number of seconds allowed for all tests to run.
|
||||
This does not include the time taken to build the tests.
|
||||
|
||||
- ``--kernel_args``: Specifies additional kernel command-line arguments. May be repeated.
|
||||
|
||||
- ``--run_isolated``: If set, boots the kernel for each individual suite/test.
|
||||
This is useful for debugging a non-hermetic test, one that
|
||||
might pass/fail based on what ran before it.
|
||||
|
||||
- ``--raw_output``: If set, generates unformatted output from kernel. Possible options are:
|
||||
|
||||
- ``all``: To view the full kernel output, use ``--raw_output=all``.
|
||||
|
||||
- ``kunit``: This is the default option and filters to KUnit output. Use ``--raw_output`` or ``--raw_output=kunit``.
|
||||
|
||||
- ``--json``: If set, stores the test results in a JSON format and prints to `stdout` or
|
||||
saves to a file if a filename is specified.
|
||||
|
||||
@ -15,7 +15,7 @@ It can be handy to create a bash function like:
|
||||
.. code-block:: bash
|
||||
|
||||
function run_kunit() {
|
||||
( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run $@ )
|
||||
( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run "$@" )
|
||||
}
|
||||
|
||||
.. note::
|
||||
@ -123,8 +123,7 @@ Putting it together into a copy-pastable sequence of commands:
|
||||
.. code-block:: bash
|
||||
|
||||
# Append coverage options to the current config
|
||||
$ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig
|
||||
$ ./tools/testing/kunit/kunit.py run
|
||||
$ ./tools/testing/kunit/kunit.py run --kunitconfig=.kunit/ --kunitconfig=tools/testing/kunit/configs/coverage_uml.config
|
||||
# Extract the coverage information from the build dir (.kunit/)
|
||||
$ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/
|
||||
|
||||
|
||||
@ -505,7 +505,7 @@ By reusing the same ``cases`` array from above, we can write the test as a
|
||||
const char *str;
|
||||
const char *sha1;
|
||||
};
|
||||
struct sha1_test_case cases[] = {
|
||||
const struct sha1_test_case cases[] = {
|
||||
{
|
||||
.str = "hello world",
|
||||
.sha1 = "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed",
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
.. title:: Kernel-doc comments
|
||||
|
||||
===========================
|
||||
Writing kernel-doc comments
|
||||
===========================
|
||||
|
||||
@ -132,7 +132,8 @@ format-specific subdirectories under ``Documentation/output``.
|
||||
To generate documentation, Sphinx (``sphinx-build``) must obviously be
|
||||
installed. For prettier HTML output, the Read the Docs Sphinx theme
|
||||
(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
|
||||
``XeLaTeX`` and ``convert(1)`` from ImageMagick (https://www.imagemagick.org).
|
||||
``XeLaTeX`` and ``convert(1)`` from ImageMagick
|
||||
(https://www.imagemagick.org).\ [#ink]_
|
||||
All of these are widely available and packaged in distributions.
|
||||
|
||||
To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
|
||||
@ -150,8 +151,19 @@ If the theme is not available, it will fall-back to the classic one.
|
||||
|
||||
The Sphinx theme can be overridden by using the ``DOCS_THEME`` make variable.
|
||||
|
||||
There is another make variable ``SPHINXDIRS``, which is useful when test
|
||||
building a subset of documentation. For example, you can build documents
|
||||
under ``Documentation/doc-guide`` by running
|
||||
``make SPHINXDIRS=doc-guide htmldocs``.
|
||||
The documentation section of ``make help`` will show you the list of
|
||||
subdirectories you can specify.
|
||||
|
||||
To remove the generated documentation, run ``make cleandocs``.
|
||||
|
||||
.. [#ink] Having ``inkscape(1)`` from Inkscape (https://inkscape.org)
|
||||
as well would improve the quality of images embedded in PDF
|
||||
documents, especially for kernel releases 5.18 and later.
|
||||
|
||||
Writing Documentation
|
||||
=====================
|
||||
|
||||
|
||||
@ -114,7 +114,7 @@ For a function using multiple GPIOs all of those can be obtained with one call::
|
||||
|
||||
This function returns a struct gpio_descs which contains an array of
|
||||
descriptors. It also contains a pointer to a gpiolib private structure which,
|
||||
if passed back to get/set array functions, may speed up I/O proocessing::
|
||||
if passed back to get/set array functions, may speed up I/O processing::
|
||||
|
||||
struct gpio_descs {
|
||||
struct gpio_array *info;
|
||||
|
||||
@ -119,7 +119,7 @@ GPIO lines with debounce support
|
||||
Debouncing is a configuration set to a pin indicating that it is connected to
|
||||
a mechanical switch or button, or similar that may bounce. Bouncing means the
|
||||
line is pulled high/low quickly at very short intervals for mechanical
|
||||
reasons. This can result in the value being unstable or irqs fireing repeatedly
|
||||
reasons. This can result in the value being unstable or irqs firing repeatedly
|
||||
unless the line is debounced.
|
||||
|
||||
Debouncing in practice involves setting up a timer when something happens on
|
||||
@ -219,7 +219,7 @@ use a trick: when a line is set as output, if the line is flagged as open
|
||||
drain, and the IN output value is low, it will be driven low as usual. But
|
||||
if the IN output value is set to high, it will instead *NOT* be driven high,
|
||||
instead it will be switched to input, as input mode is high impedance, thus
|
||||
achieveing an "open drain emulation" of sorts: electrically the behaviour will
|
||||
achieving an "open drain emulation" of sorts: electrically the behaviour will
|
||||
be identical, with the exception of possible hardware glitches when switching
|
||||
the mode of the line.
|
||||
|
||||
@ -642,7 +642,7 @@ In this case the typical set-up will look like this:
|
||||
|
||||
As you can see pretty similar, but you do not supply a parent handler for
|
||||
the IRQ, instead a parent irqdomain, an fwnode for the hardware and
|
||||
a funcion .child_to_parent_hwirq() that has the purpose of looking up
|
||||
a function .child_to_parent_hwirq() that has the purpose of looking up
|
||||
the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
|
||||
As always it is good to look at examples in the kernel tree for advice
|
||||
on how to find the required pieces.
|
||||
|
||||
@ -44,7 +44,7 @@ These devices will appear on the system as ``/dev/gpiochip0`` thru
|
||||
found in the kernel tree ``tools/gpio`` subdirectory.
|
||||
|
||||
For structured and managed applications, we recommend that you make use of the
|
||||
libgpiod_ library. This provides helper abstractions, command line utlities
|
||||
libgpiod_ library. This provides helper abstractions, command line utilities
|
||||
and arbitration for multiple simultaneous consumers on the same GPIO chip.
|
||||
|
||||
.. _libgpiod: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/
|
||||
|
||||
@ -25,8 +25,7 @@ and userspace consumers. The kernel space consumers can directly talk to HTE
|
||||
subsystem while userspace consumers timestamp requests go through GPIOLIB CDEV
|
||||
framework to HTE subsystem.
|
||||
|
||||
.. kernel-doc:: drivers/gpio/gpiolib.c
|
||||
:functions: gpiod_enable_hw_timestamp_ns gpiod_disable_hw_timestamp_ns
|
||||
See gpiod_enable_hw_timestamp_ns() and gpiod_disable_hw_timestamp_ns().
|
||||
|
||||
For userspace consumers, GPIO_V2_LINE_FLAG_EVENT_CLOCK_HTE flag must be
|
||||
specified during IOCTL calls. Refer to ``tools/gpio/gpio-event-mon.c``, which
|
||||
@ -37,7 +36,7 @@ LIC (Legacy Interrupt Controller) IRQ GTE
|
||||
|
||||
This GTE instance timestamps LIC IRQ lines in real time. There are 352 IRQ
|
||||
lines which this instance can add timestamps to in real time. The hte
|
||||
devicetree binding described at ``Documentation/devicetree/bindings/hte/``
|
||||
devicetree binding described at ``Documentation/devicetree/bindings/timestamp``
|
||||
provides an example of how a consumer can request an IRQ line. Since it is a
|
||||
one-to-one mapping with IRQ GTE provider, consumers can simply specify the IRQ
|
||||
number that they are interested in. There is no userspace consumer support for
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
#
|
||||
# Feature name: context-tracking
|
||||
# Kconfig: HAVE_CONTEXT_TRACKING
|
||||
# description: arch supports context tracking for NO_HZ_FULL
|
||||
# Feature name: user-context-tracking
|
||||
# Kconfig: HAVE_CONTEXT_TRACKING_USER
|
||||
# description: arch supports user context tracking for NO_HZ_FULL
|
||||
#
|
||||
-----------------------
|
||||
| arch |status|
|
||||
|
||||
@ -9,7 +9,7 @@
|
||||
| alpha: | TODO |
|
||||
| arc: | ok |
|
||||
| arm: | TODO |
|
||||
| arm64: | TODO |
|
||||
| arm64: | ok |
|
||||
| csky: | TODO |
|
||||
| hexagon: | TODO |
|
||||
| ia64: | TODO |
|
||||
|
||||
@ -59,8 +59,6 @@ acl Enable POSIX Access Control Lists support
|
||||
(requires CONFIG_EXT2_FS_POSIX_ACL).
|
||||
noacl Don't support POSIX ACLs.
|
||||
|
||||
nobh Do not attach buffer_heads to file pagecache.
|
||||
|
||||
quota, usrquota Enable user disk quota support
|
||||
(requires CONFIG_QUOTA).
|
||||
|
||||
|
||||
@ -818,10 +818,11 @@ Compression implementation
|
||||
Instead, the main goal is to reduce data writes to flash disk as much as
|
||||
possible, resulting in extending disk life time as well as relaxing IO
|
||||
congestion. Alternatively, we've added ioctl(F2FS_IOC_RELEASE_COMPRESS_BLOCKS)
|
||||
interface to reclaim compressed space and show it to user after putting the
|
||||
immutable bit. Immutable bit, after release, it doesn't allow writing/mmaping
|
||||
on the file, until reserving compressed space via
|
||||
ioctl(F2FS_IOC_RESERVE_COMPRESS_BLOCKS) or truncating filesize to zero.
|
||||
interface to reclaim compressed space and show it to user after setting a
|
||||
special flag to the inode. Once the compressed space is released, the flag
|
||||
will block writing data to the file until either the compressed space is
|
||||
reserved via ioctl(F2FS_IOC_RESERVE_COMPRESS_BLOCKS) or the file size is
|
||||
truncated to zero.
|
||||
|
||||
Compress metadata layout::
|
||||
|
||||
@ -830,12 +831,12 @@ Compress metadata layout::
|
||||
| cluster 1 | cluster 2 | ......... | cluster N |
|
||||
+-----------------------------------------------+
|
||||
. . . .
|
||||
. . . .
|
||||
. . . .
|
||||
. Compressed Cluster . . Normal Cluster .
|
||||
+----------+---------+---------+---------+ +---------+---------+---------+---------+
|
||||
|compr flag| block 1 | block 2 | block 3 | | block 1 | block 2 | block 3 | block 4 |
|
||||
+----------+---------+---------+---------+ +---------+---------+---------+---------+
|
||||
. .
|
||||
. .
|
||||
. .
|
||||
. .
|
||||
+-------------+-------------+----------+----------------------------+
|
||||
|
||||
@ -337,6 +337,7 @@ Currently, the following pairs of encryption modes are supported:
|
||||
- AES-256-XTS for contents and AES-256-CTS-CBC for filenames
|
||||
- AES-128-CBC for contents and AES-128-CTS-CBC for filenames
|
||||
- Adiantum for both contents and filenames
|
||||
- AES-256-XTS for contents and AES-256-HCTR2 for filenames (v2 policies only)
|
||||
|
||||
If unsure, you should use the (AES-256-XTS, AES-256-CTS-CBC) pair.
|
||||
|
||||
@ -357,6 +358,17 @@ To use Adiantum, CONFIG_CRYPTO_ADIANTUM must be enabled. Also, fast
|
||||
implementations of ChaCha and NHPoly1305 should be enabled, e.g.
|
||||
CONFIG_CRYPTO_CHACHA20_NEON and CONFIG_CRYPTO_NHPOLY1305_NEON for ARM.
|
||||
|
||||
AES-256-HCTR2 is another true wide-block encryption mode that is intended for
|
||||
use on CPUs with dedicated crypto instructions. AES-256-HCTR2 has the property
|
||||
that a bitflip in the plaintext changes the entire ciphertext. This property
|
||||
makes it desirable for filename encryption since initialization vectors are
|
||||
reused within a directory. For more details on AES-256-HCTR2, see the paper
|
||||
"Length-preserving encryption with HCTR2"
|
||||
(https://eprint.iacr.org/2021/1441.pdf). To use AES-256-HCTR2,
|
||||
CONFIG_CRYPTO_HCTR2 must be enabled. Also, fast implementations of XCTR and
|
||||
POLYVAL should be enabled, e.g. CRYPTO_POLYVAL_ARM64_CE and
|
||||
CRYPTO_AES_ARM64_CE_BLK for ARM64.
|
||||
|
||||
New encryption modes can be added relatively easily, without changes
|
||||
to individual filesystems. However, authenticated encryption (AE)
|
||||
modes are not currently supported because of the difficulty of dealing
|
||||
@ -404,11 +416,11 @@ alternatively has the file's nonce (for `DIRECT_KEY policies`_) or
|
||||
inode number (for `IV_INO_LBLK_64 policies`_) included in the IVs.
|
||||
Thus, IV reuse is limited to within a single directory.
|
||||
|
||||
With CTS-CBC, the IV reuse means that when the plaintext filenames
|
||||
share a common prefix at least as long as the cipher block size (16
|
||||
bytes for AES), the corresponding encrypted filenames will also share
|
||||
a common prefix. This is undesirable. Adiantum does not have this
|
||||
weakness, as it is a wide-block encryption mode.
|
||||
With CTS-CBC, the IV reuse means that when the plaintext filenames share a
|
||||
common prefix at least as long as the cipher block size (16 bytes for AES), the
|
||||
corresponding encrypted filenames will also share a common prefix. This is
|
||||
undesirable. Adiantum and HCTR2 do not have this weakness, as they are
|
||||
wide-block encryption modes.
|
||||
|
||||
All supported filenames encryption modes accept any plaintext length
|
||||
>= 16 bytes; cipher block alignment is not required. However,
|
||||
|
||||
@ -11,9 +11,9 @@ Introduction
|
||||
|
||||
fs-verity (``fs/verity/``) is a support layer that filesystems can
|
||||
hook into to support transparent integrity and authenticity protection
|
||||
of read-only files. Currently, it is supported by the ext4 and f2fs
|
||||
filesystems. Like fscrypt, not too much filesystem-specific code is
|
||||
needed to support fs-verity.
|
||||
of read-only files. Currently, it is supported by the ext4, f2fs, and
|
||||
btrfs filesystems. Like fscrypt, not too much filesystem-specific
|
||||
code is needed to support fs-verity.
|
||||
|
||||
fs-verity is similar to `dm-verity
|
||||
<https://www.kernel.org/doc/Documentation/device-mapper/verity.txt>`_
|
||||
@ -473,9 +473,9 @@ files being swapped around.
|
||||
Filesystem support
|
||||
==================
|
||||
|
||||
fs-verity is currently supported by the ext4 and f2fs filesystems.
|
||||
The CONFIG_FS_VERITY kconfig option must be enabled to use fs-verity
|
||||
on either filesystem.
|
||||
fs-verity is supported by several filesystems, described below. The
|
||||
CONFIG_FS_VERITY kconfig option must be enabled to use fs-verity on
|
||||
any of these filesystems.
|
||||
|
||||
``include/linux/fsverity.h`` declares the interface between the
|
||||
``fs/verity/`` support layer and filesystems. Briefly, filesystems
|
||||
@ -544,6 +544,13 @@ Currently, f2fs verity only supports a Merkle tree block size of 4096.
|
||||
Also, f2fs doesn't support enabling verity on files that currently
|
||||
have atomic or volatile writes pending.
|
||||
|
||||
btrfs
|
||||
-----
|
||||
|
||||
btrfs supports fs-verity since Linux v5.15. Verity-enabled inodes are
|
||||
marked with a RO_COMPAT inode flag, and the verity metadata is stored
|
||||
in separate btree items.
|
||||
|
||||
Implementation details
|
||||
======================
|
||||
|
||||
@ -622,14 +629,14 @@ workqueue, and then the workqueue work does the decryption or
|
||||
verification. Finally, pages where no decryption or verity error
|
||||
occurred are marked Uptodate, and the pages are unlocked.
|
||||
|
||||
Files on ext4 and f2fs may contain holes. Normally, ``->readahead()``
|
||||
simply zeroes holes and sets the corresponding pages Uptodate; no bios
|
||||
are issued. To prevent this case from bypassing fs-verity, these
|
||||
filesystems use fsverity_verify_page() to verify hole pages.
|
||||
On many filesystems, files can contain holes. Normally,
|
||||
``->readahead()`` simply zeroes holes and sets the corresponding pages
|
||||
Uptodate; no bios are issued. To prevent this case from bypassing
|
||||
fs-verity, these filesystems use fsverity_verify_page() to verify hole
|
||||
pages.
|
||||
|
||||
ext4 and f2fs disable direct I/O on verity files, since otherwise
|
||||
direct I/O would bypass fs-verity. (They also do the same for
|
||||
encrypted files.)
|
||||
Filesystems also disable direct I/O on verity files, since otherwise
|
||||
direct I/O would bypass fs-verity.
|
||||
|
||||
Userspace utility
|
||||
=================
|
||||
@ -648,7 +655,7 @@ Tests
|
||||
To test fs-verity, use xfstests. For example, using `kvm-xfstests
|
||||
<https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md>`_::
|
||||
|
||||
kvm-xfstests -c ext4,f2fs -g verity
|
||||
kvm-xfstests -c ext4,f2fs,btrfs -g verity
|
||||
|
||||
FAQ
|
||||
===
|
||||
@ -771,15 +778,15 @@ weren't already directly answered in other parts of this document.
|
||||
e.g. magically trigger construction of a Merkle tree.
|
||||
|
||||
:Q: Does fs-verity support remote filesystems?
|
||||
:A: Only ext4 and f2fs support is implemented currently, but in
|
||||
principle any filesystem that can store per-file verity metadata
|
||||
can support fs-verity, regardless of whether it's local or remote.
|
||||
Some filesystems may have fewer options of where to store the
|
||||
verity metadata; one possibility is to store it past the end of
|
||||
the file and "hide" it from userspace by manipulating i_size. The
|
||||
data verification functions provided by ``fs/verity/`` also assume
|
||||
that the filesystem uses the Linux pagecache, but both local and
|
||||
remote filesystems normally do so.
|
||||
:A: So far all filesystems that have implemented fs-verity support are
|
||||
local filesystems, but in principle any filesystem that can store
|
||||
per-file verity metadata can support fs-verity, regardless of
|
||||
whether it's local or remote. Some filesystems may have fewer
|
||||
options of where to store the verity metadata; one possibility is
|
||||
to store it past the end of the file and "hide" it from userspace
|
||||
by manipulating i_size. The data verification functions provided
|
||||
by ``fs/verity/`` also assume that the filesystem uses the Linux
|
||||
pagecache, but both local and remote filesystems normally do so.
|
||||
|
||||
:Q: Why is anything filesystem-specific at all? Shouldn't fs-verity
|
||||
be implemented entirely at the VFS level?
|
||||
|
||||
@ -252,9 +252,8 @@ prototypes::
|
||||
bool (*release_folio)(struct folio *, gfp_t);
|
||||
void (*free_folio)(struct folio *);
|
||||
int (*direct_IO)(struct kiocb *, struct iov_iter *iter);
|
||||
bool (*isolate_page) (struct page *, isolate_mode_t);
|
||||
int (*migratepage)(struct address_space *, struct page *, struct page *);
|
||||
void (*putback_page) (struct page *);
|
||||
int (*migrate_folio)(struct address_space *, struct folio *dst,
|
||||
struct folio *src, enum migrate_mode);
|
||||
int (*launder_folio)(struct folio *);
|
||||
bool (*is_partially_uptodate)(struct folio *, size_t from, size_t count);
|
||||
int (*error_remove_page)(struct address_space *, struct page *);
|
||||
@ -280,9 +279,7 @@ invalidate_folio: yes exclusive
|
||||
release_folio: yes
|
||||
free_folio: yes
|
||||
direct_IO:
|
||||
isolate_page: yes
|
||||
migratepage: yes (both)
|
||||
putback_page: yes
|
||||
migrate_folio: yes (both)
|
||||
launder_folio: yes
|
||||
is_partially_uptodate: yes
|
||||
error_remove_page: yes
|
||||
|
||||
@ -490,10 +490,6 @@ overlay filesystem and the value of st_ino for filesystem objects may not be
|
||||
persistent and could change even while the overlay filesystem is mounted, as
|
||||
summarized in the `Inode properties`_ table above.
|
||||
|
||||
4) "idmapped mounts"
|
||||
When the upper or lower layers are idmapped mounts overlayfs will be mounted
|
||||
without support for POSIX Access Control Lists (ACLs). This limitation will
|
||||
eventually be lifted.
|
||||
|
||||
Changes to underlying filesystems
|
||||
---------------------------------
|
||||
@ -635,7 +631,7 @@ can be removed.
|
||||
User xattr
|
||||
----------
|
||||
|
||||
The the "-o userxattr" mount option forces overlayfs to use the
|
||||
The "-o userxattr" mount option forces overlayfs to use the
|
||||
"user.overlay." xattr namespace instead of "trusted.overlay.". This is
|
||||
useful for unprivileged mounting of overlayfs.
|
||||
|
||||
|
||||
@ -914,3 +914,11 @@ Calling conventions for file_open_root() changed; now it takes struct path *
|
||||
instead of passing mount and dentry separately. For callers that used to
|
||||
pass <mnt, mnt->mnt_root> pair (i.e. the root of given mount), a new helper
|
||||
is provided - file_open_root_mnt(). In-tree users adjusted.
|
||||
|
||||
---
|
||||
|
||||
**mandatory**
|
||||
|
||||
no_llseek is gone; don't set .llseek to that - just leave it NULL instead.
|
||||
Checks for "does that file have llseek(2), or should it fail with ESPIPE"
|
||||
should be done by looking at FMODE_LSEEK in file->f_mode.
|
||||
|
||||
@ -737,12 +737,8 @@ cache in your filesystem. The following members are defined:
|
||||
bool (*release_folio)(struct folio *, gfp_t);
|
||||
void (*free_folio)(struct folio *);
|
||||
ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter);
|
||||
/* isolate a page for migration */
|
||||
bool (*isolate_page) (struct page *, isolate_mode_t);
|
||||
/* migrate the contents of a page to the specified target */
|
||||
int (*migratepage) (struct page *, struct page *);
|
||||
/* put migration-failed page back to right list */
|
||||
void (*putback_page) (struct page *);
|
||||
int (*migrate_folio)(struct mapping *, struct folio *dst,
|
||||
struct folio *src, enum migrate_mode);
|
||||
int (*launder_folio) (struct folio *);
|
||||
|
||||
bool (*is_partially_uptodate) (struct folio *, size_t from,
|
||||
@ -774,13 +770,38 @@ cache in your filesystem. The following members are defined:
|
||||
See the file "Locking" for more details.
|
||||
|
||||
``read_folio``
|
||||
called by the VM to read a folio from backing store. The folio
|
||||
will be locked when read_folio is called, and should be unlocked
|
||||
and marked uptodate once the read completes. If ->read_folio
|
||||
discovers that it cannot perform the I/O at this time, it can
|
||||
unlock the folio and return AOP_TRUNCATED_PAGE. In this case,
|
||||
the folio will be looked up again, relocked and if that all succeeds,
|
||||
->read_folio will be called again.
|
||||
Called by the page cache to read a folio from the backing store.
|
||||
The 'file' argument supplies authentication information to network
|
||||
filesystems, and is generally not used by block based filesystems.
|
||||
It may be NULL if the caller does not have an open file (eg if
|
||||
the kernel is performing a read for itself rather than on behalf
|
||||
of a userspace process with an open file).
|
||||
|
||||
If the mapping does not support large folios, the folio will
|
||||
contain a single page. The folio will be locked when read_folio
|
||||
is called. If the read completes successfully, the folio should
|
||||
be marked uptodate. The filesystem should unlock the folio
|
||||
once the read has completed, whether it was successful or not.
|
||||
The filesystem does not need to modify the refcount on the folio;
|
||||
the page cache holds a reference count and that will not be
|
||||
released until the folio is unlocked.
|
||||
|
||||
Filesystems may implement ->read_folio() synchronously.
|
||||
In normal operation, folios are read through the ->readahead()
|
||||
method. Only if this fails, or if the caller needs to wait for
|
||||
the read to complete will the page cache call ->read_folio().
|
||||
Filesystems should not attempt to perform their own readahead
|
||||
in the ->read_folio() operation.
|
||||
|
||||
If the filesystem cannot perform the read at this time, it can
|
||||
unlock the folio, do whatever action it needs to ensure that the
|
||||
read will succeed in the future and return AOP_TRUNCATED_PAGE.
|
||||
In this case, the caller should look up the folio, lock it,
|
||||
and call ->read_folio again.
|
||||
|
||||
Callers may invoke the ->read_folio() method directly, but using
|
||||
read_mapping_folio() will take care of locking, waiting for the
|
||||
read to complete and handle cases such as AOP_TRUNCATED_PAGE.
|
||||
|
||||
``writepages``
|
||||
called by the VM to write out pages associated with the
|
||||
@ -905,20 +926,12 @@ cache in your filesystem. The following members are defined:
|
||||
data directly between the storage and the application's address
|
||||
space.
|
||||
|
||||
``isolate_page``
|
||||
Called by the VM when isolating a movable non-lru page. If page
|
||||
is successfully isolated, VM marks the page as PG_isolated via
|
||||
__SetPageIsolated.
|
||||
|
||||
``migrate_page``
|
||||
``migrate_folio``
|
||||
This is used to compact the physical memory usage. If the VM
|
||||
wants to relocate a page (maybe off a memory card that is
|
||||
signalling imminent failure) it will pass a new page and an old
|
||||
page to this function. migrate_page should transfer any private
|
||||
data across and update any references that it has to the page.
|
||||
|
||||
``putback_page``
|
||||
Called by the VM when isolated page's migration fails.
|
||||
wants to relocate a folio (maybe from a memory device that is
|
||||
signalling imminent failure) it will pass a new folio and an old
|
||||
folio to this function. migrate_folio should transfer any private
|
||||
data across and update any references that it has to the folio.
|
||||
|
||||
``launder_folio``
|
||||
Called before freeing a folio - it writes back the dirty folio.
|
||||
|
||||
@ -21,7 +21,9 @@ specific type) associated with it.
|
||||
|
||||
In the ACPI _DSD context it is an element of the sub-package following the
|
||||
generic Device Properties UUID in the _DSD return package as specified in the
|
||||
Device Properties UUID definition document [1]_.
|
||||
section titled "Well-Known _DSD UUIDs and Data Structure Formats" sub-section
|
||||
"Device Properties UUID" in _DSD (Device Specific Data) Implementation Guide
|
||||
document [1]_.
|
||||
|
||||
It also may be regarded as the definition of a key and the associated data type
|
||||
that can be returned by _DSD in the Device Properties UUID sub-package for a
|
||||
@ -36,7 +38,9 @@ Property subsets are nested collections of properties. Each of them is
|
||||
associated with an additional key (name) allowing the subset to be referred
|
||||
to as a whole (and to be treated as a separate entity). The canonical
|
||||
representation of property subsets is via the mechanism specified in the
|
||||
Hierarchical Properties Extension UUID definition document [2]_.
|
||||
section titled "Well-Known _DSD UUIDs and Data Structure Formats" sub-section
|
||||
"Hierarchical Data Extension UUID" in _DSD (Device Specific Data)
|
||||
Implementation Guide document [1]_.
|
||||
|
||||
Property sets may be hierarchical. That is, a property set may contain
|
||||
multiple property subsets that each may contain property subsets of its
|
||||
@ -96,5 +100,4 @@ contents.
|
||||
References
|
||||
==========
|
||||
|
||||
.. [1] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
|
||||
.. [2] https://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf
|
||||
.. [1] https://github.com/UEFI/DSD-Guide
|
||||
|
||||
@ -168,7 +168,7 @@ An error injection example::
|
||||
0x00000008 Memory Correctable
|
||||
0x00000010 Memory Uncorrectable non-fatal
|
||||
# echo 0x12345000 > param1 # Set memory address for injection
|
||||
# echo $((-1 << 12)) > param2 # Mask 0xfffffffffffff000 - anywhere in this page
|
||||
# echo 0xfffffffffffff000 > param2 # Mask - anywhere in this page
|
||||
# echo 0x8 > error_type # Choose correctable memory error
|
||||
# echo 1 > error_inject # Inject now
|
||||
|
||||
|
||||
@ -9,6 +9,7 @@ Supported devices:
|
||||
* Aquacomputer Farbwerk RGB controller
|
||||
* Aquacomputer Farbwerk 360 RGB controller
|
||||
* Aquacomputer Octo fan controller
|
||||
* Aquacomputer Quadro fan controller
|
||||
|
||||
Author: Aleksa Savic
|
||||
|
||||
@ -33,6 +34,9 @@ better suited for userspace tools.
|
||||
The Octo exposes four temperature sensors and eight PWM controllable fans, along
|
||||
with their speed (in RPM), power, voltage and current.
|
||||
|
||||
The Quadro exposes four temperature sensors, a flow sensor and four PWM controllable
|
||||
fans, along with their speed (in RPM), power, voltage and current.
|
||||
|
||||
The Farbwerk and Farbwerk 360 expose four temperature sensors. Depending on the device,
|
||||
not all sysfs and debugfs entries will be available.
|
||||
|
||||
@ -45,13 +49,14 @@ the kernel and supports hotswapping.
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
================ =============================================
|
||||
================ ==============================================
|
||||
temp[1-4]_input Temperature sensors (in millidegrees Celsius)
|
||||
fan[1-2]_input Pump/fan speed (in RPM)
|
||||
power[1-2]_input Pump/fan power (in micro Watts)
|
||||
in[0-2]_input Pump/fan voltage (in milli Volts)
|
||||
curr[1-2]_input Pump/fan current (in milli Amperes)
|
||||
================ =============================================
|
||||
fan[1-8]_input Pump/fan speed (in RPM) / Flow speed (in dL/h)
|
||||
power[1-8]_input Pump/fan power (in micro Watts)
|
||||
in[0-7]_input Pump/fan voltage (in milli Volts)
|
||||
curr[1-8]_input Pump/fan current (in milli Amperes)
|
||||
pwm[1-8] Fan PWM (0 - 255)
|
||||
================ ==============================================
|
||||
|
||||
Debugfs entries
|
||||
---------------
|
||||
|
||||
@ -13,12 +13,16 @@ Supported boards:
|
||||
* ROG CROSSHAIR VIII FORMULA
|
||||
* ROG CROSSHAIR VIII HERO
|
||||
* ROG CROSSHAIR VIII IMPACT
|
||||
* ROG MAXIMUS XI HERO
|
||||
* ROG MAXIMUS XI HERO (WI-FI)
|
||||
* ROG STRIX B550-E GAMING
|
||||
* ROG STRIX B550-I GAMING
|
||||
* ROG STRIX X570-E GAMING
|
||||
* ROG STRIX X570-E GAMING WIFI II
|
||||
* ROG STRIX X570-F GAMING
|
||||
* ROG STRIX X570-I GAMING
|
||||
* ROG STRIX Z690-A GAMING WIFI D4
|
||||
* ROG ZENITH II EXTREME
|
||||
|
||||
Authors:
|
||||
- Eugene Shalygin <eugene.shalygin@gmail.com>
|
||||
|
||||
@ -46,6 +46,9 @@ temp[1-10]_input RO Temperature reading in milli-degrees
|
||||
temp[1-10]_label RO Temperature sensor label.
|
||||
=============================== ======= =======================================
|
||||
|
||||
Due to the nature of the SMM interface, each pwmX attribute controls
|
||||
fan number X.
|
||||
|
||||
Disabling automatic BIOS fan control
|
||||
------------------------------------
|
||||
|
||||
|
||||
@ -109,6 +109,7 @@ Hardware Monitoring Kernel Drivers
|
||||
lm95234
|
||||
lm95245
|
||||
lochnagar
|
||||
lt7182s
|
||||
ltc2992
|
||||
ltc2945
|
||||
ltc2947
|
||||
|
||||
@ -3,6 +3,14 @@ Kernel driver lm90
|
||||
|
||||
Supported chips:
|
||||
|
||||
* National Semiconductor LM84
|
||||
|
||||
Prefix: 'lm84'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the National Semiconductor website
|
||||
|
||||
* National Semiconductor LM90
|
||||
|
||||
Prefix: 'lm90'
|
||||
@ -43,6 +51,30 @@ Supported chips:
|
||||
|
||||
http://www.national.com/mpf/LM/LM86.html
|
||||
|
||||
* Analog Devices ADM1020
|
||||
|
||||
Prefix: 'adm1020'
|
||||
|
||||
Addresses scanned: I2C 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the Analog Devices website
|
||||
|
||||
* Analog Devices ADM1021
|
||||
|
||||
Prefix: 'adm1021'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the Analog Devices website
|
||||
|
||||
* Analog Devices ADM1021A/ADM1023
|
||||
|
||||
Prefix: 'adm1023'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the Analog Devices website
|
||||
|
||||
* Analog Devices ADM1032
|
||||
|
||||
Prefix: 'adm1032'
|
||||
@ -73,6 +105,36 @@ Supported chips:
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A
|
||||
|
||||
* Analog Devices ADT7481
|
||||
|
||||
Prefix: 'adt7481'
|
||||
|
||||
Addresses scanned: I2C 0x4b and 0x4c
|
||||
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=ADT7481
|
||||
|
||||
* Analog Devices ADT7482
|
||||
|
||||
Prefix: 'adt7482'
|
||||
|
||||
Addresses scanned: I2C 0x4c
|
||||
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=ADT7482
|
||||
|
||||
* Analog Devices ADT7483A
|
||||
|
||||
Prefix: 'adt7483a'
|
||||
|
||||
Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b, 0x4c, 0x4d, 0x4e
|
||||
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=ADT7483A
|
||||
|
||||
* ON Semiconductor NCT1008
|
||||
|
||||
Prefix: 'nct1008'
|
||||
@ -83,6 +145,72 @@ Supported chips:
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=NCT1008
|
||||
|
||||
* ON Semiconductor NCT210
|
||||
|
||||
Prefix: 'adm1021'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=NCT210
|
||||
|
||||
* ON Semiconductor NCT214
|
||||
|
||||
Prefix: 'nct214'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=NCT214
|
||||
|
||||
* ON Semiconductor NCT218
|
||||
|
||||
Prefix: 'nct218'
|
||||
|
||||
Addresses scanned: I2C 0x4c - 0x4d
|
||||
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=NCT218
|
||||
|
||||
* ON Semiconductor NCT72
|
||||
|
||||
Prefix: 'nct72'
|
||||
|
||||
Addresses scanned: I2C 0x4c - 0x4d
|
||||
|
||||
Datasheet: Publicly available at the ON Semiconductor website
|
||||
|
||||
https://www.onsemi.com/PowerSolutions/product.do?id=NCT72
|
||||
|
||||
* Maxim MAX1617
|
||||
|
||||
Prefix: 'max1617'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
|
||||
* Maxim MAX1617A
|
||||
|
||||
Prefix: 'max1617a'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
|
||||
* Maxim MAX6642
|
||||
|
||||
Prefix: 'max6642'
|
||||
|
||||
Addresses scanned: I2C 0x48-0x4f
|
||||
|
||||
Datasheet: Publicly available at the Maxim website
|
||||
|
||||
http://datasheets.maxim-ic.com/en/ds/MAX6642.pdf
|
||||
|
||||
* Maxim MAX6646
|
||||
|
||||
Prefix: 'max6646'
|
||||
@ -105,7 +233,7 @@ Supported chips:
|
||||
|
||||
* Maxim MAX6648
|
||||
|
||||
Prefix: 'max6646'
|
||||
Prefix: 'max6648'
|
||||
|
||||
Addresses scanned: I2C 0x4c
|
||||
|
||||
@ -191,7 +319,7 @@ Supported chips:
|
||||
|
||||
* Maxim MAX6692
|
||||
|
||||
Prefix: 'max6646'
|
||||
Prefix: 'max6648'
|
||||
|
||||
Addresses scanned: I2C 0x4c
|
||||
|
||||
@ -275,6 +403,46 @@ Supported chips:
|
||||
|
||||
https://www.ti.com/lit/gpn/tmp461
|
||||
|
||||
* Philips NE1617, NE1617A
|
||||
|
||||
Prefix: 'max1617' (probably detected as a max1617)
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheets: Publicly available at the Philips website
|
||||
|
||||
* Philips NE1618
|
||||
|
||||
Prefix: 'ne1618'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheets: Publicly available at the Philips website
|
||||
|
||||
* Genesys Logic GL523SM
|
||||
|
||||
Prefix: 'gl523sm'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet:
|
||||
|
||||
* TI THMC10
|
||||
|
||||
Prefix: 'thmc10'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the TI website
|
||||
|
||||
* Onsemi MC1066
|
||||
|
||||
Prefix: 'mc1066'
|
||||
|
||||
Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
|
||||
|
||||
Datasheet: Publicly available at the Onsemi website
|
||||
|
||||
Author: Jean Delvare <jdelvare@suse.de>
|
||||
|
||||
|
||||
@ -285,6 +453,12 @@ The LM90 is a digital temperature sensor. It senses its own temperature as
|
||||
well as the temperature of up to one external diode. It is compatible
|
||||
with many other devices, many of which are supported by this driver.
|
||||
|
||||
The family of chips supported by this driver is derived from MAX1617.
|
||||
This chip as well as various compatible chips support a local and a remote
|
||||
temperature sensor with 8 bit accuracy. Later chips provide improved accuracy
|
||||
and other additional features such as hysteresis and temperature offset
|
||||
registers.
|
||||
|
||||
Note that there is no easy way to differentiate between the MAX6657,
|
||||
MAX6658 and MAX6659 variants. The extra features of the MAX6659 are only
|
||||
supported by this driver if the chip is located at address 0x4d or 0x4e,
|
||||
@ -292,15 +466,31 @@ or if the chip type is explicitly selected as max6659.
|
||||
The MAX6680 and MAX6681 only differ in their pinout, therefore they obviously
|
||||
can't (and don't need to) be distinguished.
|
||||
|
||||
The specificity of this family of chipsets over the ADM1021/LM84
|
||||
family is that it features critical limits with hysteresis, and an
|
||||
increased resolution of the remote temperature measurement.
|
||||
|
||||
The different chipsets of the family are not strictly identical, although
|
||||
very similar. For reference, here comes a non-exhaustive list of specific
|
||||
features:
|
||||
|
||||
LM84:
|
||||
* 8 bit sensor resolution
|
||||
|
||||
ADM1020, ADM1021, GL523SM, MAX1617, NE1617, NE1617A, THMC10:
|
||||
* 8 bit sensor resolution
|
||||
* Low temperature limits
|
||||
|
||||
NCT210, NE1618:
|
||||
* 11 bit sensor resolution for remote temperature sensor
|
||||
* Low temperature limits
|
||||
|
||||
ADM1021A, ADM1023:
|
||||
* Temperature offset register for remote temperature sensor
|
||||
* 11 bit resolution for remote temperature sensor
|
||||
* Low temperature limits
|
||||
|
||||
LM90:
|
||||
* 11 bit resolution for remote temperature sensor
|
||||
* Temperature offset register for remote temperature sensor
|
||||
* Low and critical temperature limits
|
||||
* Configurable conversion rate
|
||||
* Filter and alert configuration register at 0xBF.
|
||||
* ALERT is triggered by temperatures over critical limits.
|
||||
|
||||
@ -322,8 +512,31 @@ ADM1032:
|
||||
ADT7461, ADT7461A, NCT1008:
|
||||
* Extended temperature range (breaks compatibility)
|
||||
* Lower resolution for remote temperature
|
||||
* SMBus PEC support for Write Byte and Receive Byte transactions.
|
||||
* 10 bit temperature resolution
|
||||
|
||||
MAX6654:
|
||||
ADT7481, ADT7482, ADT7483:
|
||||
* Temperature offset register
|
||||
* SMBus PEC support
|
||||
* 10 bit temperature resolution for external sensors
|
||||
* Two remote sensors
|
||||
* Selectable address (ADT7483)
|
||||
|
||||
MAX6642:
|
||||
* No critical limit register
|
||||
* Conversion rate not configurable
|
||||
* Better local resolution (10 bit)
|
||||
* 10 bit external sensor resolution
|
||||
|
||||
MAX6646, MAX6647, MAX6649:
|
||||
* Better local resolution
|
||||
* Extended range unsigned external temperature
|
||||
|
||||
MAX6648, MAX6692:
|
||||
* Better local resolution
|
||||
* Unsigned temperature
|
||||
|
||||
MAX6654, MAX6690:
|
||||
* Better local resolution
|
||||
* Selectable address
|
||||
* Remote sensor type selection
|
||||
@ -423,6 +636,6 @@ two transactions will typically mean twice as much delay waiting for
|
||||
transaction completion, effectively doubling the register cache refresh time.
|
||||
I guess reliability comes at a price, but it's quite expensive this time.
|
||||
|
||||
So, as not everyone might enjoy the slowdown, PEC can be disabled through
|
||||
sysfs. Just write 0 to the "pec" file and PEC will be disabled. Write 1
|
||||
to that file to enable PEC again.
|
||||
So, as not everyone might enjoy the slowdown, PEC is disabled by default and
|
||||
can be enabled through sysfs. Just write 1 to the "pec" file and PEC will be
|
||||
enabled. Write 0 to that file to disable PEC again.
|
||||
|
||||
92
Documentation/hwmon/lt7182s.rst
Normal file
92
Documentation/hwmon/lt7182s.rst
Normal file
@ -0,0 +1,92 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Kernel driver lt7182s
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
|
||||
* ADI LT7182S
|
||||
|
||||
Prefix: 'lt7182s'
|
||||
|
||||
Addresses scanned: -
|
||||
|
||||
Datasheet: https://www.analog.com/en/products/lt7182s.html
|
||||
|
||||
Author: Guenter Roeck <linux@roeck-us.net>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
LT7182S is a Dual Channel 6A, 20V PolyPhase Step-Down Silent Switcher with
|
||||
Digital Power System Management support.
|
||||
|
||||
|
||||
Usage Notes
|
||||
-----------
|
||||
|
||||
This driver does not probe for PMBus devices. You will have to instantiate
|
||||
devices explicitly.
|
||||
|
||||
Example: the following commands will load the driver for a LT7182S
|
||||
at address 0x4f on I2C bus #4::
|
||||
|
||||
# modprobe lt7182s
|
||||
# echo lt7182s 0x4f > /sys/bus/i2c/devices/i2c-4/new_device
|
||||
|
||||
It can also be instantiated by declaring an entry in device tree.
|
||||
|
||||
|
||||
Sysfs attributes
|
||||
----------------
|
||||
|
||||
======================= ====================================
|
||||
curr[1-2]_label "iin[12]"
|
||||
curr[1-2]_input Measured input current
|
||||
curr[1-2]_max Maximum input current
|
||||
curr[1-2]_max_alarm Current high alarm
|
||||
|
||||
curr[3-4]_label "iout[1-2]"
|
||||
curr[3-4]_input Measured output current
|
||||
curr[3-4]_highest Highest measured output current
|
||||
curr[3-4]_max Maximum output current
|
||||
curr[3-4]_max_alarm Output current high alarm
|
||||
|
||||
in[1-2]_label "vin[12]"
|
||||
in[1-2]_input Measured input voltage
|
||||
in[1-2]_highest Highest measured input voltage
|
||||
in[1-2]_crit Critical maximum input voltage
|
||||
in[1-2]_crit_alarm Input voltage critical high alarm
|
||||
in[1-2]_min Minimum input voltage
|
||||
in[1-2]_min_alarm Input voltage low alarm
|
||||
in[1-2]_rated_min Rated minimum input voltage
|
||||
in[1-2]_rated_max Rated maximum input voltage
|
||||
in1_reset_history Write to reset history for all attributes
|
||||
|
||||
in[3-5]_label "vmon[1-3]"
|
||||
in[3-5]_input Measured voltage on ITH1/ITH2/EXTVCC pins
|
||||
Only available if enabled with MFR_ADC_CONTROL_LT7182S
|
||||
command.
|
||||
|
||||
in[3-4|6-7]_label "vout[1-2]"
|
||||
in[3-4|6-7]_input Measured output voltage
|
||||
in[3-4|6-7]_highest Highest measured output voltage
|
||||
in[3-4|6-7]_lcrit Critical minimum output voltage
|
||||
in[3-4|6-7]_lcrit_alarm Output voltage critical low alarm
|
||||
in[3-4|6-7]_min Minimum output voltage
|
||||
in[3-4|6-7]_max_alarm Output voltage low alarm
|
||||
in[3-4|6-7]_max Maximum output voltage
|
||||
in[3-4|6-7]_max_alarm Output voltage high alarm
|
||||
in[3-4|6-7]_crit Critical maximum output voltage
|
||||
in[3-4|6-7]_crit_alarm Output voltage critical high alarm
|
||||
|
||||
power[1-2]_label "pout[1-2]"
|
||||
power[1-2]_input Measured output power
|
||||
|
||||
temp1_input Measured temperature
|
||||
temp1_crit Critical high temperature
|
||||
temp1_crit_alarm Chip temperature critical high alarm
|
||||
temp1_max Maximum temperature
|
||||
temp1_max_alarm Chip temperature high alarm
|
||||
======================= ====================================
|
||||
@ -121,6 +121,15 @@ Specifically, it provides the following information.
|
||||
non-standard PMBus commands to standard commands, or to augment standard
|
||||
command return values with device specific information.
|
||||
|
||||
PEC Support
|
||||
===========
|
||||
|
||||
Many PMBus devices support SMBus PEC (Packet Error Checking). If supported
|
||||
by both the I2C adapter and by the PMBus chip, it is by default enabled.
|
||||
If PEC is supported, the PMBus core driver adds an attribute named 'pec' to
|
||||
the I2C device. This attribute can be used to control PEC support in the
|
||||
communication with the PMBus chip.
|
||||
|
||||
API functions
|
||||
=============
|
||||
|
||||
|
||||
@ -12,7 +12,6 @@ increase the chances of your change being accepted.
|
||||
* It should be unnecessary to mention, but please read and follow:
|
||||
|
||||
- Documentation/process/submit-checklist.rst
|
||||
- Documentation/process/submitting-drivers.rst
|
||||
- Documentation/process/submitting-patches.rst
|
||||
- Documentation/process/coding-style.rst
|
||||
|
||||
|
||||
@ -755,8 +755,7 @@ make a neat patch, there's administrative work to be done:
|
||||
it implies a more-than-passing commitment to some part of the code.
|
||||
|
||||
- Finally, don't forget to read
|
||||
``Documentation/process/submitting-patches.rst`` and possibly
|
||||
``Documentation/process/submitting-drivers.rst``.
|
||||
``Documentation/process/submitting-patches.rst``
|
||||
|
||||
Kernel Cantrips
|
||||
===============
|
||||
|
||||
@ -1894,6 +1894,7 @@ There are some more advanced barrier functions:
|
||||
|
||||
(*) dma_wmb();
|
||||
(*) dma_rmb();
|
||||
(*) dma_mb();
|
||||
|
||||
These are for use with consistent memory to guarantee the ordering
|
||||
of writes or reads of shared memory accessible to both the CPU and a
|
||||
@ -1925,11 +1926,11 @@ There are some more advanced barrier functions:
|
||||
The dma_rmb() allows us guarantee the device has released ownership
|
||||
before we read the data from the descriptor, and the dma_wmb() allows
|
||||
us to guarantee the data is written to the descriptor before the device
|
||||
can see it now has ownership. Note that, when using writel(), a prior
|
||||
wmb() is not needed to guarantee that the cache coherent memory writes
|
||||
have completed before writing to the MMIO region. The cheaper
|
||||
writel_relaxed() does not provide this guarantee and must not be used
|
||||
here.
|
||||
can see it now has ownership. The dma_mb() implies both a dma_rmb() and
|
||||
a dma_wmb(). Note that, when using writel(), a prior wmb() is not needed
|
||||
to guarantee that the cache coherent memory writes have completed before
|
||||
writing to the MMIO region. The cheaper writel_relaxed() does not provide
|
||||
this guarantee and must not be used here.
|
||||
|
||||
See the subsection "Kernel I/O barrier effects" for more information on
|
||||
relaxed I/O accessors and the Documentation/core-api/dma-api.rst file for
|
||||
|
||||
@ -20,20 +20,20 @@ possible source of information on its own, the EM framework intervenes as an
|
||||
abstraction layer which standardizes the format of power cost tables in the
|
||||
kernel, hence enabling to avoid redundant work.
|
||||
|
||||
The power values might be expressed in milli-Watts or in an 'abstract scale'.
|
||||
The power values might be expressed in micro-Watts or in an 'abstract scale'.
|
||||
Multiple subsystems might use the EM and it is up to the system integrator to
|
||||
check that the requirements for the power value scale types are met. An example
|
||||
can be found in the Energy-Aware Scheduler documentation
|
||||
Documentation/scheduler/sched-energy.rst. For some subsystems like thermal or
|
||||
powercap power values expressed in an 'abstract scale' might cause issues.
|
||||
These subsystems are more interested in estimation of power used in the past,
|
||||
thus the real milli-Watts might be needed. An example of these requirements can
|
||||
thus the real micro-Watts might be needed. An example of these requirements can
|
||||
be found in the Intelligent Power Allocation in
|
||||
Documentation/driver-api/thermal/power_allocator.rst.
|
||||
Kernel subsystems might implement automatic detection to check whether EM
|
||||
registered devices have inconsistent scale (based on EM internal flag).
|
||||
Important thing to keep in mind is that when the power values are expressed in
|
||||
an 'abstract scale' deriving real energy in milli-Joules would not be possible.
|
||||
an 'abstract scale' deriving real energy in micro-Joules would not be possible.
|
||||
|
||||
The figure below depicts an example of drivers (Arm-specific here, but the
|
||||
approach is applicable to any architecture) providing power costs to the EM
|
||||
@ -98,7 +98,7 @@ Drivers are expected to register performance domains into the EM framework by
|
||||
calling the following API::
|
||||
|
||||
int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states,
|
||||
struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts);
|
||||
struct em_data_callback *cb, cpumask_t *cpus, bool microwatts);
|
||||
|
||||
Drivers must provide a callback function returning <frequency, power> tuples
|
||||
for each performance state. The callback function provided by the driver is free
|
||||
@ -106,10 +106,10 @@ to fetch data from any relevant location (DT, firmware, ...), and by any mean
|
||||
deemed necessary. Only for CPU devices, drivers must specify the CPUs of the
|
||||
performance domains using cpumask. For other devices than CPUs the last
|
||||
argument must be set to NULL.
|
||||
The last argument 'milliwatts' is important to set with correct value. Kernel
|
||||
The last argument 'microwatts' is important to set with correct value. Kernel
|
||||
subsystems which use EM might rely on this flag to check if all EM devices use
|
||||
the same scale. If there are different scales, these subsystems might decide
|
||||
to: return warning/error, stop working or panic.
|
||||
to return warning/error, stop working or panic.
|
||||
See Section 3. for an example of driver implementing this
|
||||
callback, or Section 2.4 for further documentation on this API
|
||||
|
||||
@ -137,7 +137,7 @@ The .get_cost() allows to provide the 'cost' values which reflect the
|
||||
efficiency of the CPUs. This would allow to provide EAS information which
|
||||
has different relation than what would be forced by the EM internal
|
||||
formulas calculating 'cost' values. To register an EM for such platform, the
|
||||
driver must set the flag 'milliwatts' to 0, provide .get_power() callback
|
||||
driver must set the flag 'microwatts' to 0, provide .get_power() callback
|
||||
and provide .get_cost() callback. The EM framework would handle such platform
|
||||
properly during registration. A flag EM_PERF_DOMAIN_ARTIFICIAL is set for such
|
||||
platform. Special care should be taken by other frameworks which are using EM
|
||||
|
||||
@ -315,7 +315,7 @@ that these callbacks operate on::
|
||||
configuration space */
|
||||
unsigned int pme_support:5; /* Bitmask of states from which PME#
|
||||
can be generated */
|
||||
unsigned int pme_interrupt:1;/* Is native PCIe PME signaling used? */
|
||||
unsigned int pme_poll:1; /* Poll device's PME status bit */
|
||||
unsigned int d1_support:1; /* Low power state D1 is supported */
|
||||
unsigned int d2_support:1; /* Low power state D2 is supported */
|
||||
unsigned int no_d1d2:1; /* D1 and D2 are forbidden */
|
||||
|
||||
@ -10,8 +10,7 @@ of conventions and procedures which are used in the posting of patches;
|
||||
following them will make life much easier for everybody involved. This
|
||||
document will attempt to cover these expectations in reasonable detail;
|
||||
more information can also be found in the files
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`,
|
||||
:ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
and :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`.
|
||||
|
||||
|
||||
|
||||
@ -5,15 +5,13 @@ For more information
|
||||
|
||||
There are numerous sources of information on Linux kernel development and
|
||||
related topics. First among those will always be the Documentation
|
||||
directory found in the kernel source distribution. The top-level :ref:`process/howto.rst <process_howto>`
|
||||
file is an important starting point; :ref:`process/submitting-patches.rst <submittingpatches>`
|
||||
and :ref:`process/submitting-drivers.rst <submittingdrivers>`
|
||||
are also something which all kernel developers should
|
||||
read. Many internal kernel APIs are documented using the kerneldoc
|
||||
mechanism; "make htmldocs" or "make pdfdocs" can be used to generate those
|
||||
documents in HTML or PDF format (though the version of TeX shipped by some
|
||||
distributions runs into internal limits and fails to process the documents
|
||||
properly).
|
||||
directory found in the kernel source distribution. Start with the
|
||||
top-level :ref:`process/howto.rst <process_howto>`; also read
|
||||
:ref:`process/submitting-patches.rst <submittingpatches>`. Many internal
|
||||
kernel APIs are documented using the kerneldoc mechanism; "make htmldocs"
|
||||
or "make pdfdocs" can be used to generate those documents in HTML or PDF
|
||||
format (though the version of TeX shipped by some distributions runs into
|
||||
internal limits and fails to process the documents properly).
|
||||
|
||||
Various web sites discuss kernel development at all levels of detail. Your
|
||||
author would like to humbly suggest https://lwn.net/ as a source;
|
||||
|
||||
@ -277,36 +277,61 @@ Thunderbird (GUI)
|
||||
Thunderbird is an Outlook clone that likes to mangle text, but there are ways
|
||||
to coerce it into behaving.
|
||||
|
||||
- Allow use of an external editor:
|
||||
The easiest thing to do with Thunderbird and patches is to use an
|
||||
"external editor" extension and then just use your favorite ``$EDITOR``
|
||||
for reading/merging patches into the body text. To do this, download
|
||||
and install the extension, then add a button for it using
|
||||
:menuselection:`View-->Toolbars-->Customize...` and finally just click on it
|
||||
when in the :menuselection:`Compose` dialog.
|
||||
After doing the modifications, this includes installing the extensions,
|
||||
you need to restart Thunderbird.
|
||||
|
||||
Please note that "external editor" requires that your editor must not
|
||||
fork, or in other words, the editor must not return before closing.
|
||||
You may have to pass additional flags or change the settings of your
|
||||
editor. Most notably if you are using gvim then you must pass the -f
|
||||
option to gvim by putting ``/usr/bin/gvim -f`` (if the binary is in
|
||||
``/usr/bin``) to the text editor field in :menuselection:`external editor`
|
||||
settings. If you are using some other editor then please read its manual
|
||||
to find out how to do this.
|
||||
- Allow use of an external editor:
|
||||
|
||||
The easiest thing to do with Thunderbird and patches is to use extensions
|
||||
which open your favorite external editor.
|
||||
|
||||
Here are some example extensions which are capable of doing this.
|
||||
|
||||
- "External Editor Revived"
|
||||
|
||||
https://github.com/Frederick888/external-editor-revived
|
||||
|
||||
https://addons.thunderbird.net/en-GB/thunderbird/addon/external-editor-revived/
|
||||
|
||||
It requires installing a "native messaging host".
|
||||
Please read the wiki which can be found here:
|
||||
https://github.com/Frederick888/external-editor-revived/wiki
|
||||
|
||||
- "External Editor"
|
||||
|
||||
https://github.com/exteditor/exteditor
|
||||
|
||||
To do this, download and install the extension, then open the
|
||||
:menuselection:`compose` window, add a button for it using
|
||||
:menuselection:`View-->Toolbars-->Customize...`
|
||||
then just click on the new button when you wish to use the external editor.
|
||||
|
||||
Please note that "External Editor" requires that your editor must not
|
||||
fork, or in other words, the editor must not return before closing.
|
||||
You may have to pass additional flags or change the settings of your
|
||||
editor. Most notably if you are using gvim then you must pass the -f
|
||||
option to gvim by putting ``/usr/bin/gvim --nofork"`` (if the binary is in
|
||||
``/usr/bin``) to the text editor field in :menuselection:`external editor`
|
||||
settings. If you are using some other editor then please read its manual
|
||||
to find out how to do this.
|
||||
|
||||
To beat some sense out of the internal editor, do this:
|
||||
|
||||
- Edit your Thunderbird config settings so that it won't use ``format=flowed``.
|
||||
Go to :menuselection:`edit-->preferences-->advanced-->config editor` to bring up
|
||||
the thunderbird's registry editor.
|
||||
- Edit your Thunderbird config settings so that it won't use ``format=flowed``!
|
||||
Go to your main window and find the button for your main dropdown menu.
|
||||
:menuselection:`Main Menu-->Preferences-->General-->Config Editor...`
|
||||
to bring up the thunderbird's registry editor.
|
||||
|
||||
- Set ``mailnews.send_plaintext_flowed`` to ``false``
|
||||
- Set ``mailnews.send_plaintext_flowed`` to ``false``
|
||||
|
||||
- Set ``mailnews.wraplength`` from ``72`` to ``0``
|
||||
- Set ``mailnews.wraplength`` from ``72`` to ``0``
|
||||
|
||||
- :menuselection:`View-->Message Body As-->Plain Text`
|
||||
- Don't write HTML messages! Go to the main window
|
||||
:menuselection:`Main Menu-->Account Settings-->youracc@server.something-->Composition & Addressing`!
|
||||
There you can disable the option "Compose messages in HTML format".
|
||||
|
||||
- :menuselection:`View-->Character Encoding-->Unicode (UTF-8)`
|
||||
- Open messages only as plain text! Go to the main window
|
||||
:menuselection:`Main Menu-->View-->Message Body As-->Plain Text`!
|
||||
|
||||
TkRat (GUI)
|
||||
***********
|
||||
|
||||
@ -105,8 +105,8 @@ required reading:
|
||||
patches if these rules are followed, and many people will only
|
||||
review code if it is in the proper style.
|
||||
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>` and :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
These files describe in explicit detail how to successfully create
|
||||
:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
This file describes in explicit detail how to successfully create
|
||||
and send a patch, including (but not limited to):
|
||||
|
||||
- Email contents
|
||||
|
||||
@ -40,7 +40,6 @@ Other guides to the community that are of interest to most developers are:
|
||||
:maxdepth: 1
|
||||
|
||||
changes
|
||||
submitting-drivers
|
||||
stable-api-nonsense
|
||||
management-style
|
||||
stable-kernel-rules
|
||||
|
||||
@ -1,9 +1,10 @@
|
||||
.. _kernel_docs:
|
||||
|
||||
Index of Documentation for People Interested in Writing and/or Understanding the Linux Kernel
|
||||
=============================================================================================
|
||||
Index of Further Kernel Documentation
|
||||
=====================================
|
||||
|
||||
Juan-Mariano de Goyeneche <jmseyas@dit.upm.es>
|
||||
Initial Author: Juan-Mariano de Goyeneche (<jmseyas@dit.upm.es>;
|
||||
email address is defunct now.)
|
||||
|
||||
The need for a document like this one became apparent in the
|
||||
linux-kernel mailing list as the same questions, asking for pointers
|
||||
@ -16,21 +17,16 @@ philosophy and design decisions behind this code.
|
||||
|
||||
Unfortunately, not many documents are available for beginners to
|
||||
start. And, even if they exist, there was no "well-known" place which
|
||||
kept track of them. These lines try to cover this lack. All documents
|
||||
available on line known by the author are listed, while some reference
|
||||
books are also mentioned.
|
||||
kept track of them. These lines try to cover this lack.
|
||||
|
||||
PLEASE, if you know any paper not listed here or write a new document,
|
||||
send me an e-mail, and I'll include a reference to it here. Any
|
||||
corrections, ideas or comments are also welcomed.
|
||||
include a reference to it here, following the kernel's patch submission
|
||||
process. Any corrections, ideas or comments are also welcome.
|
||||
|
||||
The papers that follow are listed in no particular order. All are
|
||||
cataloged with the following fields: the document's "Title", the
|
||||
"Author"/s, the "URL" where they can be found, some "Keywords" helpful
|
||||
when searching for specific topics, and a brief "Description" of the
|
||||
Document.
|
||||
|
||||
Enjoy!
|
||||
All documents are cataloged with the following fields: the document's
|
||||
"Title", the "Author"/s, the "URL" where they can be found, some
|
||||
"Keywords" helpful when searching for specific topics, and a brief
|
||||
"Description" of the Document.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -83,6 +79,18 @@ On-line docs
|
||||
Finally this trace-log is used as base for more a exact conceptual
|
||||
exploration and description of the Linux TCP/IP implementation.*
|
||||
|
||||
* Title: **The Linux Kernel Module Programming Guide**
|
||||
|
||||
:Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram,
|
||||
Jim Huang.
|
||||
:URL: https://sysprog21.github.io/lkmpg/
|
||||
:Date: 2021
|
||||
:Keywords: modules, GPL book, /proc, ioctls, system calls,
|
||||
interrupt handlers .
|
||||
:Description: A very nice GPL book on the topic of modules
|
||||
programming. Lots of examples. Currently the new version is being
|
||||
actively maintained at https://github.com/sysprog21/lkmpg.
|
||||
|
||||
* Title: **On submitting kernel Patches**
|
||||
|
||||
:Author: Andi Kleen
|
||||
@ -126,17 +134,19 @@ On-line docs
|
||||
describes how to write user-mode utilities for communicating with
|
||||
Card Services.
|
||||
|
||||
* Title: **The Linux Kernel Module Programming Guide**
|
||||
* Title: **How NOT to write kernel drivers**
|
||||
|
||||
:Author: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram,
|
||||
Jim Huang.
|
||||
:URL: https://sysprog21.github.io/lkmpg/
|
||||
:Date: 2021
|
||||
:Keywords: modules, GPL book, /proc, ioctls, system calls,
|
||||
interrupt handlers .
|
||||
:Description: A very nice GPL book on the topic of modules
|
||||
programming. Lots of examples. Currently the new version is being
|
||||
actively maintained at https://github.com/sysprog21/lkmpg.
|
||||
:Author: Arjan van de Ven.
|
||||
:URL: https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf
|
||||
:Date: 2002
|
||||
:Keywords: driver.
|
||||
:Description: Programming bugs and Do-nots in kernel driver development
|
||||
:Abstract: *Quit a few tutorials, articles and books give an introduction
|
||||
on how to write Linux kernel drivers. Unfortunately the things one
|
||||
should NOT do in Linux kernel code is either only a minor appendix
|
||||
or, more commonly, completely absent. This paper tries to briefly touch
|
||||
the areas in which the most common and serious bugs and do-nots are
|
||||
encountered.*
|
||||
|
||||
* Title: **Global spinlock list and usage**
|
||||
|
||||
|
||||
@ -1,194 +0,0 @@
|
||||
.. _submittingdrivers:
|
||||
|
||||
Submitting Drivers For The Linux Kernel
|
||||
=======================================
|
||||
|
||||
This document is intended to explain how to submit device drivers to the
|
||||
various kernel trees. Note that if you are interested in video card drivers
|
||||
you should probably talk to XFree86 (https://www.xfree86.org/) and/or X.Org
|
||||
(https://x.org/) instead.
|
||||
|
||||
.. note::
|
||||
|
||||
This document is old and has seen little maintenance in recent years; it
|
||||
should probably be updated or, perhaps better, just deleted. Most of
|
||||
what is here can be found in the other development documents anyway.
|
||||
|
||||
Oh, and we don't really recommend submitting changes to XFree86 :)
|
||||
|
||||
Also read the :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
|
||||
document.
|
||||
|
||||
|
||||
Allocating Device Numbers
|
||||
-------------------------
|
||||
|
||||
Major and minor numbers for block and character devices are allocated
|
||||
by the Linux assigned name and number authority (currently this is
|
||||
Torben Mathiasen). The site is https://www.lanana.org/. This
|
||||
also deals with allocating numbers for devices that are not going to
|
||||
be submitted to the mainstream kernel.
|
||||
See :ref:`Documentation/admin-guide/devices.rst <admin_devices>`
|
||||
for more information on this.
|
||||
|
||||
If you don't use assigned numbers then when your device is submitted it will
|
||||
be given an assigned number even if that is different from values you may
|
||||
have shipped to customers before.
|
||||
|
||||
Who To Submit Drivers To
|
||||
------------------------
|
||||
|
||||
Linux 2.0:
|
||||
No new drivers are accepted for this kernel tree.
|
||||
|
||||
Linux 2.2:
|
||||
No new drivers are accepted for this kernel tree.
|
||||
|
||||
Linux 2.4:
|
||||
If the code area has a general maintainer then please submit it to
|
||||
the maintainer listed in MAINTAINERS in the kernel file. If the
|
||||
maintainer does not respond or you cannot find the appropriate
|
||||
maintainer then please contact Willy Tarreau <w@1wt.eu>.
|
||||
|
||||
Linux 2.6 and upper:
|
||||
The same rules apply as 2.4 except that you should follow linux-kernel
|
||||
to track changes in API's. The final contact point for Linux 2.6+
|
||||
submissions is Andrew Morton.
|
||||
|
||||
What Criteria Determine Acceptance
|
||||
----------------------------------
|
||||
|
||||
Licensing:
|
||||
The code must be released to us under the
|
||||
GNU General Public License. If you wish the driver to be
|
||||
useful to other communities such as BSD you may release
|
||||
under multiple licenses. If you choose to release under
|
||||
licenses other than the GPL, you should include your
|
||||
rationale for your license choices in your cover letter.
|
||||
See accepted licenses at include/linux/module.h
|
||||
|
||||
Copyright:
|
||||
The copyright owner must agree to use of GPL.
|
||||
It's best if the submitter and copyright owner
|
||||
are the same person/entity. If not, the name of
|
||||
the person/entity authorizing use of GPL should be
|
||||
listed in case it's necessary to verify the will of
|
||||
the copyright owner.
|
||||
|
||||
Interfaces:
|
||||
If your driver uses existing interfaces and behaves like
|
||||
other drivers in the same class it will be much more likely
|
||||
to be accepted than if it invents gratuitous new ones.
|
||||
If you need to implement a common API over Linux and NT
|
||||
drivers do it in userspace.
|
||||
|
||||
Code:
|
||||
Please use the Linux style of code formatting as documented
|
||||
in :ref:`Documentation/process/coding-style.rst <codingStyle>`.
|
||||
If you have sections of code
|
||||
that need to be in other formats, for example because they
|
||||
are shared with a windows driver kit and you want to
|
||||
maintain them just once separate them out nicely and note
|
||||
this fact.
|
||||
|
||||
Portability:
|
||||
Pointers are not always 32bits, not all computers are little
|
||||
endian, people do not all have floating point and you
|
||||
shouldn't use inline x86 assembler in your driver without
|
||||
careful thought. Pure x86 drivers generally are not popular.
|
||||
If you only have x86 hardware it is hard to test portability
|
||||
but it is easy to make sure the code can easily be made
|
||||
portable.
|
||||
|
||||
Clarity:
|
||||
It helps if anyone can see how to fix the driver. It helps
|
||||
you because you get patches not bug reports. If you submit a
|
||||
driver that intentionally obfuscates how the hardware works
|
||||
it will go in the bitbucket.
|
||||
|
||||
PM support:
|
||||
Since Linux is used on many portable and desktop systems, your
|
||||
driver is likely to be used on such a system and therefore it
|
||||
should support basic power management by implementing, if
|
||||
necessary, the .suspend and .resume methods used during the
|
||||
system-wide suspend and resume transitions. You should verify
|
||||
that your driver correctly handles the suspend and resume, but
|
||||
if you are unable to ensure that, please at least define the
|
||||
.suspend method returning the -ENOSYS ("Function not
|
||||
implemented") error. You should also try to make sure that your
|
||||
driver uses as little power as possible when it's not doing
|
||||
anything. For the driver testing instructions see
|
||||
Documentation/power/drivers-testing.rst and for a relatively
|
||||
complete overview of the power management issues related to
|
||||
drivers see :ref:`Documentation/driver-api/pm/devices.rst <driverapi_pm_devices>`.
|
||||
|
||||
Control:
|
||||
In general if there is active maintenance of a driver by
|
||||
the author then patches will be redirected to them unless
|
||||
they are totally obvious and without need of checking.
|
||||
If you want to be the contact and update point for the
|
||||
driver it is a good idea to state this in the comments,
|
||||
and include an entry in MAINTAINERS for your driver.
|
||||
|
||||
What Criteria Do Not Determine Acceptance
|
||||
-----------------------------------------
|
||||
|
||||
Vendor:
|
||||
Being the hardware vendor and maintaining the driver is
|
||||
often a good thing. If there is a stable working driver from
|
||||
other people already in the tree don't expect 'we are the
|
||||
vendor' to get your driver chosen. Ideally work with the
|
||||
existing driver author to build a single perfect driver.
|
||||
|
||||
Author:
|
||||
It doesn't matter if a large Linux company wrote the driver,
|
||||
or you did. Nobody has any special access to the kernel
|
||||
tree. Anyone who tells you otherwise isn't telling the
|
||||
whole story.
|
||||
|
||||
|
||||
Resources
|
||||
---------
|
||||
|
||||
Linux kernel master tree:
|
||||
ftp.\ *country_code*\ .kernel.org:/pub/linux/kernel/...
|
||||
|
||||
where *country_code* == your country code, such as
|
||||
**us**, **uk**, **fr**, etc.
|
||||
|
||||
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git
|
||||
|
||||
Linux kernel mailing list:
|
||||
linux-kernel@vger.kernel.org
|
||||
[mail majordomo@vger.kernel.org to subscribe]
|
||||
|
||||
Linux Device Drivers, Third Edition (covers 2.6.10):
|
||||
https://lwn.net/Kernel/LDD3/ (free version)
|
||||
|
||||
LWN.net:
|
||||
Weekly summary of kernel development activity - https://lwn.net/
|
||||
|
||||
2.6 API changes:
|
||||
|
||||
https://lwn.net/Articles/2.6-kernel-api/
|
||||
|
||||
Porting drivers from prior kernels to 2.6:
|
||||
|
||||
https://lwn.net/Articles/driver-porting/
|
||||
|
||||
KernelNewbies:
|
||||
Documentation and assistance for new kernel programmers
|
||||
|
||||
https://kernelnewbies.org/
|
||||
|
||||
Linux USB project:
|
||||
http://www.linux-usb.org/
|
||||
|
||||
How to NOT write kernel driver by Arjan van de Ven:
|
||||
https://landley.net/kdocs/ols/2002/ols2002-pages-545-555.pdf
|
||||
|
||||
Kernel Janitor:
|
||||
https://kernelnewbies.org/KernelJanitors
|
||||
|
||||
GIT, Fast Version Control System:
|
||||
https://git-scm.com/
|
||||
@ -12,9 +12,8 @@ This document contains a large number of suggestions in a relatively terse
|
||||
format. For detailed information on how the kernel development process
|
||||
works, see Documentation/process/development-process.rst. Also, read
|
||||
Documentation/process/submit-checklist.rst
|
||||
for a list of items to check before submitting code. If you are submitting
|
||||
a driver, also read Documentation/process/submitting-drivers.rst; for device
|
||||
tree binding patches, read
|
||||
for a list of items to check before submitting code.
|
||||
For device tree binding patches, read
|
||||
Documentation/devicetree/bindings/submitting-patches.rst.
|
||||
|
||||
This documentation assumes that you're using ``git`` to prepare your patches.
|
||||
|
||||
@ -87,8 +87,7 @@ with the command.
|
||||
1.2.2 Completing a scmd w/ timeout
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The timeout handler is scsi_times_out(). When a timeout occurs, this
|
||||
function
|
||||
The timeout handler is scsi_timeout(). When a timeout occurs, this function
|
||||
|
||||
1. invokes optional hostt->eh_timed_out() callback. Return value can
|
||||
be one of
|
||||
|
||||
@ -731,7 +731,7 @@ Details::
|
||||
* Notes: If 'no_async_abort' is defined this callback
|
||||
* will be invoked from scsi_eh thread. No other commands
|
||||
* will then be queued on current host during eh.
|
||||
* Otherwise it will be called whenever scsi_times_out()
|
||||
* Otherwise it will be called whenever scsi_timeout()
|
||||
* is called due to a command timeout.
|
||||
*
|
||||
* Optionally defined in: LLD
|
||||
|
||||
@ -1046,7 +1046,7 @@ The keyctl syscall functions are:
|
||||
"filter" is either NULL to remove a watch or a filter specification to
|
||||
indicate what events are required from the key.
|
||||
|
||||
See Documentation/watch_queue.rst for more information.
|
||||
See Documentation/core-api/watch_queue.rst for more information.
|
||||
|
||||
Note that only one watch may be emplaced for any particular { key,
|
||||
queue_fd } combination.
|
||||
|
||||
@ -98,6 +98,6 @@ References
|
||||
|
||||
See [sev-api-spec]_ for more info regarding SEV ``LAUNCH_SECRET`` operation.
|
||||
|
||||
.. [sev] Documentation/virt/kvm/amd-memory-encryption.rst
|
||||
.. [sev] Documentation/virt/kvm/x86/amd-memory-encryption.rst
|
||||
.. [secrets-coco-abi] Documentation/ABI/testing/securityfs-secrets-coco
|
||||
.. [sev-api-spec] https://www.amd.com/system/files/TechDocs/55766_SEV-KM_API_Specification.pdf
|
||||
|
||||
@ -85,7 +85,7 @@ Often times the XuY functions will not be large enough, and instead you'll
|
||||
want to pass a pre-filled struct to siphash. When doing this, it's important
|
||||
to always ensure the struct has no padding holes. The easiest way to do this
|
||||
is to simply arrange the members of the struct in descending order of size,
|
||||
and to use offsetendof() instead of sizeof() for getting the size. For
|
||||
and to use offsetofend() instead of sizeof() for getting the size. For
|
||||
performance reasons, if possible, it's probably a good thing to align the
|
||||
struct to the right boundary. Here's an example::
|
||||
|
||||
|
||||
@ -120,14 +120,21 @@ def markup_refs(docname, app, node):
|
||||
repl.append(nodes.Text(t[done:]))
|
||||
return repl
|
||||
|
||||
#
|
||||
# Keep track of cross-reference lookups that failed so we don't have to
|
||||
# do them again.
|
||||
#
|
||||
failed_lookups = { }
|
||||
def failure_seen(target):
|
||||
return (target) in failed_lookups
|
||||
def note_failure(target):
|
||||
failed_lookups[target] = True
|
||||
|
||||
#
|
||||
# In sphinx3 we can cross-reference to C macro and function, each one with its
|
||||
# own C role, but both match the same regex, so we try both.
|
||||
#
|
||||
def markup_func_ref_sphinx3(docname, app, match):
|
||||
class_str = ['c-func', 'c-macro']
|
||||
reftype_str = ['function', 'macro']
|
||||
|
||||
cdom = app.env.domains['c']
|
||||
#
|
||||
# Go through the dance of getting an xref out of the C domain
|
||||
@ -143,27 +150,28 @@ def markup_func_ref_sphinx3(docname, app, match):
|
||||
|
||||
if base_target not in Skipnames:
|
||||
for target in possible_targets:
|
||||
if target not in Skipfuncs:
|
||||
for class_s, reftype_s in zip(class_str, reftype_str):
|
||||
lit_text = nodes.literal(classes=['xref', 'c', class_s])
|
||||
lit_text += target_text
|
||||
pxref = addnodes.pending_xref('', refdomain = 'c',
|
||||
reftype = reftype_s,
|
||||
reftarget = target, modname = None,
|
||||
classname = None)
|
||||
#
|
||||
# XXX The Latex builder will throw NoUri exceptions here,
|
||||
# work around that by ignoring them.
|
||||
#
|
||||
try:
|
||||
xref = cdom.resolve_xref(app.env, docname, app.builder,
|
||||
reftype_s, target, pxref,
|
||||
lit_text)
|
||||
except NoUri:
|
||||
xref = None
|
||||
if (target not in Skipfuncs) and not failure_seen(target):
|
||||
lit_text = nodes.literal(classes=['xref', 'c', 'c-func'])
|
||||
lit_text += target_text
|
||||
pxref = addnodes.pending_xref('', refdomain = 'c',
|
||||
reftype = 'function',
|
||||
reftarget = target,
|
||||
modname = None,
|
||||
classname = None)
|
||||
#
|
||||
# XXX The Latex builder will throw NoUri exceptions here,
|
||||
# work around that by ignoring them.
|
||||
#
|
||||
try:
|
||||
xref = cdom.resolve_xref(app.env, docname, app.builder,
|
||||
'function', target, pxref,
|
||||
lit_text)
|
||||
except NoUri:
|
||||
xref = None
|
||||
|
||||
if xref:
|
||||
return xref
|
||||
if xref:
|
||||
return xref
|
||||
note_failure(target)
|
||||
|
||||
return target_text
|
||||
|
||||
|
||||
@ -201,9 +201,6 @@ static_key->entry field makes use of the two least significant bits.
|
||||
* ``void arch_jump_label_transform(struct jump_entry *entry, enum jump_label_type type)``,
|
||||
see: arch/x86/kernel/jump_label.c
|
||||
|
||||
* ``__init_or_module void arch_jump_label_transform_static(struct jump_entry *entry, enum jump_label_type type)``,
|
||||
see: arch/x86/kernel/jump_label.c
|
||||
|
||||
* ``struct jump_entry``,
|
||||
see: arch/x86/include/asm/jump_label.h
|
||||
|
||||
|
||||
@ -0,0 +1,11 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../../disclaimer-ita.rst
|
||||
|
||||
:Original: Documentation/devicetree/bindings/submitting-patches.rst
|
||||
|
||||
================================================
|
||||
Sottomettere patch per devicetree (DT) *binding*
|
||||
================================================
|
||||
|
||||
.. note:: to be translated
|
||||
@ -5,6 +5,7 @@
|
||||
|
||||
.. _it_kernel_doc:
|
||||
|
||||
=================================
|
||||
Scrivere i commenti in kernel-doc
|
||||
=================================
|
||||
|
||||
@ -469,6 +470,7 @@ Il titolo che segue ``DOC:`` funziona da intestazione all'interno del file
|
||||
sorgente, ma anche come identificatore per l'estrazione di questi commenti di
|
||||
documentazione. Quindi, il titolo dev'essere unico all'interno del file.
|
||||
|
||||
=======================================
|
||||
Includere i commenti di tipo kernel-doc
|
||||
=======================================
|
||||
|
||||
|
||||
@ -5,8 +5,9 @@
|
||||
|
||||
.. _it_sphinxdoc:
|
||||
|
||||
Introduzione
|
||||
============
|
||||
=============================================
|
||||
Usare Sphinx per la documentazione del kernel
|
||||
=============================================
|
||||
|
||||
Il kernel Linux usa `Sphinx`_ per la generazione della documentazione a partire
|
||||
dai file `reStructuredText`_ che si trovano nella cartella ``Documentation``.
|
||||
@ -158,6 +159,9 @@ Per poter passare ulteriori opzioni a Sphinx potete utilizzare la variabile
|
||||
make ``SPHINXOPTS``. Per esempio, se volete che Sphinx sia più verboso durante
|
||||
la generazione potete usare il seguente comando ``make SPHINXOPTS=-v htmldocs``.
|
||||
|
||||
Potete anche personalizzare l'ouptut html passando un livello aggiuntivo
|
||||
DOCS_CSS usando la rispettiva variabile d'ambiente ``DOCS_CSS``.
|
||||
|
||||
Potete eliminare la documentazione generata tramite il comando
|
||||
``make cleandocs``.
|
||||
|
||||
@ -276,11 +280,11 @@ incrociato quando questa ha una voce nell'indice. Se trovate degli usi di
|
||||
Tabelle a liste
|
||||
---------------
|
||||
|
||||
Raccomandiamo l'uso delle tabelle in formato lista (*list table*). Le tabelle
|
||||
in formato lista sono liste di liste. In confronto all'ASCII-art potrebbero
|
||||
non apparire di facile lettura nei file in formato testo. Il loro vantaggio è
|
||||
che sono facili da creare o modificare e che la differenza di una modifica è
|
||||
molto più significativa perché limitata alle modifiche del contenuto.
|
||||
Il formato ``list-table`` può essere utile per tutte quelle tabelle che non
|
||||
possono essere facilmente scritte usando il formato ASCII-art di Sphinx. Però,
|
||||
questo genere di tabelle sono illeggibili per chi legge direttamente i file di
|
||||
testo. Dunque, questo formato dovrebbe essere evitato senza forti argomenti che
|
||||
ne giustifichino l'uso.
|
||||
|
||||
La ``flat-table`` è anch'essa una lista di liste simile alle ``list-table``
|
||||
ma con delle funzionalità aggiuntive:
|
||||
|
||||
@ -129,8 +129,7 @@ eseguiti simultaneamente.
|
||||
.. warning::
|
||||
|
||||
Il nome 'tasklet' è ingannevole: non hanno niente a che fare
|
||||
con i 'processi' ('tasks'), e probabilmente hanno più a che vedere
|
||||
con qualche pessima vodka che Alexey Kuznetsov si fece a quel tempo.
|
||||
con i 'processi' ('tasks').
|
||||
|
||||
Potete determinate se siete in un softirq (o tasklet) utilizzando la
|
||||
macro :c:func:`in_softirq()` (``include/linux/preempt.h``).
|
||||
@ -308,7 +307,7 @@ esse copiano una quantità arbitraria di dati da e verso lo spazio utente.
|
||||
Al contrario di:c:func:`put_user()` e :c:func:`get_user()`, queste
|
||||
funzioni ritornano la quantità di dati copiati (0 è comunque un successo).
|
||||
|
||||
[Sì, questa stupida interfaccia mi imbarazza. La battaglia torna in auge anno
|
||||
[Sì, questa interfaccia mi imbarazza. La battaglia torna in auge anno
|
||||
dopo anno. --RR]
|
||||
|
||||
Le funzioni potrebbero dormire implicitamente. Queste non dovrebbero mai essere
|
||||
@ -679,9 +678,8 @@ tutti sulle spine: questo riflette cambiamenti fondamentati (eg. la funzione
|
||||
non può più essere chiamata con le funzioni attive, o fa controlli aggiuntivi,
|
||||
o non fa più controlli che venivano fatti in precedenza). Solitamente a questo
|
||||
s'accompagna un'adeguata e completa nota sulla lista di discussone
|
||||
linux-kernel; cercate negli archivi.
|
||||
Solitamente eseguire una semplice sostituzione su tutto un file rendere
|
||||
le cose **peggiori**.
|
||||
più adatta; cercate negli archivi. Solitamente eseguire una semplice
|
||||
sostituzione su tutto un file rendere le cose **peggiori**.
|
||||
|
||||
Inizializzazione dei campi d'una struttura
|
||||
------------------------------------------
|
||||
@ -759,14 +757,14 @@ Mettere le vostre cose nel kernel
|
||||
Al fine d'avere le vostre cose in ordine per l'inclusione ufficiale, o
|
||||
anche per avere patch pulite, c'è del lavoro amministrativo da fare:
|
||||
|
||||
- Trovare di chi è lo stagno in cui state pisciando. Guardare in cima
|
||||
- Trovare chi è responsabile del codice che state modificando. Guardare in cima
|
||||
ai file sorgenti, all'interno del file ``MAINTAINERS``, ed alla fine
|
||||
di tutti nel file ``CREDITS``. Dovreste coordinarvi con queste persone
|
||||
per evitare di duplicare gli sforzi, o provare qualcosa che è già stato
|
||||
rigettato.
|
||||
|
||||
Assicuratevi di mettere il vostro nome ed indirizzo email in cima a
|
||||
tutti i file che create o che mangeggiate significativamente. Questo è
|
||||
tutti i file che create o che maneggiate significativamente. Questo è
|
||||
il primo posto dove le persone guarderanno quando troveranno un baco,
|
||||
o quando **loro** vorranno fare una modifica.
|
||||
|
||||
@ -787,16 +785,15 @@ anche per avere patch pulite, c'è del lavoro amministrativo da fare:
|
||||
"obj-$(CONFIG_xxx) += xxx.o". La sintassi è documentata nel file
|
||||
``Documentation/kbuild/makefiles.rst``.
|
||||
|
||||
- Aggiungete voi stessi in ``CREDITS`` se avete fatto qualcosa di notevole,
|
||||
solitamente qualcosa che supera il singolo file (comunque il vostro nome
|
||||
dovrebbe essere all'inizio dei file sorgenti). ``MAINTAINERS`` significa
|
||||
- Aggiungete voi stessi in ``CREDITS`` se credete di aver fatto qualcosa di
|
||||
notevole, solitamente qualcosa che supera il singolo file (comunque il vostro
|
||||
nome dovrebbe essere all'inizio dei file sorgenti). ``MAINTAINERS`` significa
|
||||
che volete essere consultati quando vengono fatte delle modifiche ad un
|
||||
sottosistema, e quando ci sono dei bachi; questo implica molto di più
|
||||
di un semplice impegno su una parte del codice.
|
||||
sottosistema, e quando ci sono dei bachi; questo implica molto di più di un
|
||||
semplice impegno su una parte del codice.
|
||||
|
||||
- Infine, non dimenticatevi di leggere
|
||||
``Documentation/process/submitting-patches.rst`` e possibilmente anche
|
||||
``Documentation/process/submitting-drivers.rst``.
|
||||
``Documentation/process/submitting-patches.rst``.
|
||||
|
||||
Trucchetti del kernel
|
||||
=====================
|
||||
|
||||
@ -102,16 +102,11 @@ che non esistano.
|
||||
Sincronizzazione nel kernel Linux
|
||||
=================================
|
||||
|
||||
Se posso darvi un suggerimento: non dormite mai con qualcuno più pazzo di
|
||||
voi. Ma se dovessi darvi un suggerimento sulla sincronizzazione:
|
||||
**mantenetela semplice**.
|
||||
Se dovessi darvi un suggerimento sulla sincronizzazione: **mantenetela
|
||||
semplice**.
|
||||
|
||||
Siate riluttanti nell'introduzione di nuovi *lock*.
|
||||
|
||||
Abbastanza strano, quest'ultimo è l'esatto opposto del mio suggerimento
|
||||
su quando **avete** dormito con qualcuno più pazzo di voi. E dovreste
|
||||
pensare a prendervi un cane bello grande.
|
||||
|
||||
I due principali tipi di *lock* nel kernel: spinlock e mutex
|
||||
------------------------------------------------------------
|
||||
|
||||
@ -316,7 +311,7 @@ Pete Zaitcev ci offre il seguente riassunto:
|
||||
|
||||
- Se siete in un contesto utente (una qualsiasi chiamata di sistema)
|
||||
e volete sincronizzarvi con altri processi, usate i mutex. Potete trattenere
|
||||
il mutex e dormire (``copy_from_user*(`` o ``kmalloc(x,GFP_KERNEL)``).
|
||||
il mutex e dormire (``copy_from_user(`` o ``kmalloc(x,GFP_KERNEL)``).
|
||||
|
||||
- Altrimenti (== i dati possono essere manipolati da un'interruzione) usate
|
||||
spin_lock_irqsave() e spin_unlock_irqrestore().
|
||||
@ -979,9 +974,6 @@ fallisce nel trovare quello che vuole, quindi rilascia il *lock* di lettura,
|
||||
trattiene un *lock* di scrittura ed inserisce un oggetto; questo genere di
|
||||
codice presenta una corsa critica.
|
||||
|
||||
Se non riuscite a capire il perché, per favore state alla larga dal mio
|
||||
codice.
|
||||
|
||||
corsa fra temporizzatori: un passatempo del kernel
|
||||
--------------------------------------------------
|
||||
|
||||
|
||||
@ -0,0 +1,10 @@
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: Documentation/process/botching-up-ioctls.rst
|
||||
|
||||
.. _it_configuregit:
|
||||
|
||||
Configurare Git
|
||||
===============
|
||||
|
||||
.. note:: To be translated
|
||||
@ -1,6 +1,6 @@
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: :ref:`Documentation/networking/netdev-FAQ.rst <netdev-FAQ>`
|
||||
:Original: :ref:`Documentation/process/maintainer-netdev.rst <netdev-FAQ>`
|
||||
|
||||
.. _it_netdev-FAQ:
|
||||
|
||||
|
||||
@ -168,14 +168,15 @@ in questa ricerca:
|
||||
|
||||
.../scripts/get_maintainer.pl
|
||||
|
||||
Se questo script viene eseguito con l'opzione "-f" ritornerà il
|
||||
manutentore(i) attuale per un dato file o cartella. Se viene passata una
|
||||
patch sulla linea di comando, lo script elencherà i manutentori che
|
||||
dovrebbero riceverne una copia. Ci sono svariate opzioni che regolano
|
||||
quanto a fondo get_maintainer.pl debba cercare i manutentori;
|
||||
siate quindi prudenti nell'utilizzare le opzioni più aggressive poiché
|
||||
potreste finire per includere sviluppatori che non hanno un vero interesse
|
||||
per il codice che state modificando.
|
||||
Se questo script viene eseguito con l'opzione "-f" ritornerà il manutentore(i)
|
||||
attuale per un dato file o cartella. Se viene passata una patch sulla linea di
|
||||
comando, lo script elencherà i manutentori che dovrebbero riceverne una copia.
|
||||
Questo è la maniera raccomandata (non quella con "-f") per ottenere la lista di
|
||||
persone da aggiungere a Cc per le vostre patch. Ci sono svariate opzioni che
|
||||
regolano quanto a fondo get_maintainer.pl debba cercare i manutentori; siate
|
||||
quindi prudenti nell'utilizzare le opzioni più aggressive poiché potreste finire
|
||||
per includere sviluppatori che non hanno un vero interesse per il codice che
|
||||
state modificando.
|
||||
|
||||
Se tutto ciò dovesse fallire, parlare con Andrew Morton potrebbe essere
|
||||
un modo efficace per capire chi è il manutentore di un dato pezzo di codice.
|
||||
|
||||
@ -16,9 +16,8 @@ e di procedure per la pubblicazione delle patch; seguirle renderà la vita
|
||||
più facile a tutti quanti. Questo documento cercherà di coprire questi
|
||||
argomenti con un ragionevole livello di dettaglio; più informazioni possono
|
||||
essere trovare nella cartella 'Documentation', nei file
|
||||
:ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`,
|
||||
:ref:`translations/it_IT/process/submitting-drivers.rst <it_submittingdrivers>`, e
|
||||
:ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.
|
||||
:ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
|
||||
e :ref:`translations/it_IT/process/submit-checklist.rst <it_submitchecklist>`.
|
||||
|
||||
|
||||
Quando pubblicarle
|
||||
@ -214,13 +213,28 @@ irrilevanti (quelli generati dal processo di generazione, per esempio, o i file
|
||||
di backup del vostro editor). Il file "dontdiff" nella cartella Documentation
|
||||
potrà esservi d'aiuto su questo punto; passatelo a diff con l'opzione "-X".
|
||||
|
||||
Le etichette sopra menzionante sono usate per descrivere come i vari
|
||||
sviluppatori sono stati associati allo sviluppo di una patch. Sono descritte
|
||||
in dettaglio nel documento :ref:`translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`;
|
||||
quello che segue è un breve riassunto. Ognuna di queste righe ha il seguente
|
||||
formato:
|
||||
Le etichette sopracitate danno un'idea di come una patch prende vita e sono
|
||||
descritte nel dettaglio nel documento
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.
|
||||
Qui di seguito un breve riassunto.
|
||||
|
||||
::
|
||||
Un'etichetta ci può dire quale commit ha introdotto il problema che viene corretto nella patch::
|
||||
|
||||
Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
|
||||
|
||||
Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti
|
||||
maggiori informazioni, per esempio un rapporto circa il baco risolto dalla
|
||||
patch, oppure un documento con le specifiche implementate dalla patch::
|
||||
|
||||
Link: https://example.com/somewhere.html optional-other-stuff
|
||||
|
||||
Alcuni manutentori aggiungono quest'etichetta alla patch per fare riferimento
|
||||
alla più recente discussione pubblica. A volte questo è fatto automaticamente da
|
||||
alcuni strumenti come b4 or un *hook* git come quello descritto qui
|
||||
'Documentation/translations/it_IT/maintainer/configure-git.rst'
|
||||
|
||||
Un terzo tipo di etichetta viene usato per indicare chi ha contribuito allo
|
||||
sviluppo della patch. Tutte queste etichette seguono il formato::
|
||||
|
||||
tag: Full Name <email address> optional-other-stuff
|
||||
|
||||
|
||||
@ -13,9 +13,8 @@ e argomenti correlati. Primo tra questi sarà sempre la cartella Documentation
|
||||
che si trova nei sorgenti kernel.
|
||||
|
||||
Il file :ref:`process/howto.rst <it_process_howto>` è un punto di partenza
|
||||
importante; :ref:`process/submitting-patches.rst <it_submittingpatches>` e
|
||||
:ref:`process/submitting-drivers.rst <it_submittingdrivers>` sono
|
||||
anch'essi qualcosa che tutti gli sviluppatori del kernel dovrebbero leggere.
|
||||
importante; :ref:`process/submitting-patches.rst <it_submittingpatches>` è
|
||||
anch'esso qualcosa che tutti gli sviluppatori del kernel dovrebbero leggere.
|
||||
Molte API interne al kernel sono documentate utilizzando il meccanismo
|
||||
kerneldoc; "make htmldocs" o "make pdfdocs" possono essere usati per generare
|
||||
quei documenti in HTML o PDF (sebbene le versioni di TeX di alcune
|
||||
|
||||
@ -11,8 +11,8 @@ Requisiti minimi per compilare il kernel
|
||||
Introduzione
|
||||
============
|
||||
|
||||
Questo documento fornisce una lista dei software necessari per eseguire i
|
||||
kernel 4.x.
|
||||
Questo documento fornisce una lista dei software necessari per eseguire questa
|
||||
versione del kernel.
|
||||
|
||||
Questo documento è basato sul file "Changes" del kernel 2.0.x e quindi le
|
||||
persone che lo scrissero meritano credito (Jared Mauch, Axel Boldt,
|
||||
@ -32,12 +32,13 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils.
|
||||
====================== ================= ========================================
|
||||
Programma Versione minima Comando per verificare la versione
|
||||
====================== ================= ========================================
|
||||
GNU C 4.9 gcc --version
|
||||
Clang/LLVM (optional) 10.0.1 clang --version
|
||||
GNU C 5.1 gcc --version
|
||||
Clang/LLVM (optional) 11.0.0 clang --version
|
||||
GNU make 3.81 make --version
|
||||
binutils 2.23 ld -v
|
||||
flex 2.5.35 flex --version
|
||||
bison 2.0 bison --version
|
||||
pahole 1.16 pahole --version
|
||||
util-linux 2.10o fdformat --version
|
||||
kmod 13 depmod -V
|
||||
e2fsprogs 1.41.4 e2fsck -V
|
||||
@ -58,6 +59,7 @@ 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
|
||||
cpio any cpio --version
|
||||
====================== ================= ========================================
|
||||
|
||||
.. [#f1] Sphinx è necessario solo per produrre la documentazione del Kernel
|
||||
@ -111,6 +113,16 @@ Bison
|
||||
Dalla versione 4.16, il sistema di compilazione, durante l'esecuzione, genera
|
||||
un parsificatore. Questo richiede bison 2.0 o successivo.
|
||||
|
||||
pahole
|
||||
------
|
||||
|
||||
Dalla versione 5.2, quando viene impostato CONFIG_DEBUG_INFO_BTF, il sistema di
|
||||
compilazione genera BTF (BPF Type Format) a partire da DWARF per vmlinux. Più
|
||||
tardi anche per i moduli. Questo richiede pahole v1.16 o successivo.
|
||||
|
||||
A seconda della distribuzione, lo si può trovare nei pacchetti 'dwarves' o
|
||||
'pahole'. Oppure lo si può trovare qui: https://fedorapeople.org/~acme/dwarves/.
|
||||
|
||||
Perl
|
||||
----
|
||||
|
||||
@ -455,6 +467,11 @@ mcelog
|
||||
|
||||
- <http://www.mcelog.org/>
|
||||
|
||||
cpio
|
||||
----
|
||||
|
||||
- <https://www.gnu.org/software/cpio/>
|
||||
|
||||
Rete
|
||||
****
|
||||
|
||||
|
||||
@ -466,14 +466,52 @@ la riga della parentesi graffa di chiusura. Ad esempio:
|
||||
}
|
||||
EXPORT_SYMBOL(system_is_up);
|
||||
|
||||
6.1) Prototipi di funzione
|
||||
**************************
|
||||
|
||||
Nei prototipi di funzione, includete i nomi dei parametri e i loro tipi.
|
||||
Nonostante questo non sia richiesto dal linguaggio C, in Linux viene preferito
|
||||
perché è un modo semplice per aggiungere informazioni importanti per il
|
||||
lettore.
|
||||
|
||||
Non usate la parola chiave ``extern`` coi prototipi di funzione perché
|
||||
Non usate la parola chiave ``extern`` con le dichiarazioni di funzione perché
|
||||
rende le righe più lunghe e non è strettamente necessario.
|
||||
|
||||
Quando scrivete i prototipi di funzione mantenete `l'ordine degli elementi <https://lore.kernel.org/mm-commits/CAHk-=wiOCLRny5aifWNhr621kYrJwhfURsa0vFPeUEm8mF0ufg@mail.gmail.com/>`_.
|
||||
|
||||
Prendiamo questa dichiarazione di funzione come esempio::
|
||||
|
||||
__init void * __must_check action(enum magic value, size_t size, u8 count,
|
||||
char *fmt, ...) __printf(4, 5) __malloc;
|
||||
|
||||
L'ordine suggerito per gli elementi di un prototipo di funzione è il seguente:
|
||||
|
||||
- classe d'archiviazione (in questo caso ``static __always_inline``. Da notare
|
||||
che ``__always_inline`` è tecnicamente un attributo ma che viene trattato come
|
||||
``inline``)
|
||||
- attributi della classe di archiviazione (in questo caso ``__init``, in altre
|
||||
parole la sezione, ma anche cose tipo ``__cold``)
|
||||
- il tipo di ritorno (in questo caso, ``void *``)
|
||||
- attributi per il valore di ritorno (in questo caso, ``__must_check``)
|
||||
- il nome della funzione (in questo caso, ``action``)
|
||||
- i parametri della funzione(in questo caso,
|
||||
``(enum magic value, size_t size, u8 count, char *fmt, ...)``,
|
||||
da notare che va messo anche il nome del parametro)
|
||||
- attributi dei parametri (in questo caso, ``__printf(4, 5)``)
|
||||
- attributi per il comportamento della funzione (in questo caso, ``__malloc_``)
|
||||
|
||||
Notate che per la **definizione** di una funzione (il altre parole il corpo
|
||||
della funzione), il compilatore non permette di usare gli attributi per i
|
||||
parametri dopo i parametri. In questi casi, devono essere messi dopo gli
|
||||
attributi della classe d'archiviazione (notate che la posizione di
|
||||
``__printf(4,5)`` cambia rispetto alla **dichiarazione**)::
|
||||
|
||||
static __always_inline __init __printf(4, 5) void * __must_check action(enum magic value,
|
||||
size_t size, u8 count, char *fmt, ...) __malloc
|
||||
{
|
||||
...
|
||||
}*)**``)**``)``)``*)``)``)``)``*``)``)``)*)
|
||||
|
||||
7) Centralizzare il ritorno delle funzioni
|
||||
------------------------------------------
|
||||
|
||||
@ -855,7 +893,7 @@ I messaggi del kernel non devono terminare con un punto fermo.
|
||||
Scrivere i numeri fra parentesi (%d) non migliora alcunché e per questo
|
||||
dovrebbero essere evitati.
|
||||
|
||||
Ci sono alcune macro per la diagnostica in <linux/device.h> che dovreste
|
||||
Ci sono alcune macro per la diagnostica in <linux/dev_printk.h> che dovreste
|
||||
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
|
||||
|
||||
@ -69,8 +69,8 @@ dovrebbero essere fatto negli argomenti di funzioni di allocazione di memoria
|
||||
piccoli di quelli che il chiamante si aspettava. L'uso di questo modo di
|
||||
allocare può portare ad un overflow della memoria di heap e altri
|
||||
malfunzionamenti. (Si fa eccezione per valori numerici per i quali il
|
||||
compilatore può generare avvisi circa un potenziale overflow. Tuttavia usare
|
||||
i valori numerici come suggerito di seguito è innocuo).
|
||||
compilatore può generare avvisi circa un potenziale overflow. Tuttavia, anche in
|
||||
questi casi è preferibile riscrivere il codice come suggerito di seguito).
|
||||
|
||||
Per esempio, non usate ``count * size`` come argomento::
|
||||
|
||||
@ -80,6 +80,9 @@ Al suo posto, si dovrebbe usare l'allocatore a due argomenti::
|
||||
|
||||
foo = kmalloc_array(count, size, GFP_KERNEL);
|
||||
|
||||
Nello specifico, kmalloc() può essere sostituta da kmalloc_array(), e kzalloc()
|
||||
da kcalloc().
|
||||
|
||||
Se questo tipo di allocatore non è disponibile, allora dovrebbero essere usate
|
||||
le funzioni del tipo *saturate-on-overflow*::
|
||||
|
||||
@ -100,9 +103,20 @@ Invece, usate la seguente funzione::
|
||||
invitati a riorganizzare il vostro codice usando il
|
||||
`flexible array member <#zero-length-and-one-element-arrays>`_.
|
||||
|
||||
Per maggiori dettagli fate riferimento a array_size(),
|
||||
array3_size(), e struct_size(), così come la famiglia di
|
||||
funzioni check_add_overflow() e check_mul_overflow().
|
||||
Per altri calcoli, usate le funzioni size_mul(), size_add(), e size_sub(). Per
|
||||
esempio, al posto di::
|
||||
|
||||
foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL);
|
||||
|
||||
dovreste scrivere:
|
||||
|
||||
foo = krealloc(size_add(current_size,
|
||||
size_mul(chunk_size,
|
||||
size_sub(count, 3))), GFP_KERNEL);
|
||||
|
||||
Per maggiori dettagli fate riferimento a array3_size() e flex_array_size(), ma
|
||||
anche le funzioni della famiglia check_mul_overflow(), check_add_overflow(),
|
||||
check_sub_overflow(), e check_shl_overflow().
|
||||
|
||||
simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull()
|
||||
----------------------------------------------------------------------
|
||||
|
||||
@ -109,8 +109,7 @@ Di seguito una lista di file che sono presenti nei sorgente del kernel e che
|
||||
accetteranno patch solo se queste osserveranno tali regole, e molte
|
||||
persone revisioneranno il codice solo se scritto nello stile appropriato.
|
||||
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>` e
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-drivers.rst <it_submittingdrivers>`
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
|
||||
|
||||
Questo file descrive dettagliatamente come creare ed inviare una patch
|
||||
con successo, includendo (ma non solo questo):
|
||||
|
||||
@ -41,12 +41,12 @@ degli sviluppatori:
|
||||
:maxdepth: 1
|
||||
|
||||
changes
|
||||
submitting-drivers
|
||||
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.
|
||||
|
||||
@ -0,0 +1,24 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: Documentation/process/maintainer-handbooks.rst
|
||||
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
|
||||
|
||||
.. _it_maintainer_handbooks_main:
|
||||
|
||||
Note sul processo di sviluppo dei sottosistemi e dei sorgenti dei manutentori
|
||||
=============================================================================
|
||||
|
||||
Lo scopo di questo documento è quello di fornire informazioni sul processo di
|
||||
sviluppo dedicate ai sottosistemi che vanno ad integrare quelle più generali
|
||||
descritte in :ref:`Documentation/translations/it_IT/process
|
||||
<it_development_process_main>`.
|
||||
|
||||
Indice:
|
||||
|
||||
.. toctree::
|
||||
:numbered:
|
||||
:maxdepth: 2
|
||||
|
||||
maintainer-tip
|
||||
@ -931,12 +931,11 @@ che avete nel vostro portachiavi::
|
||||
uid [ unknown] Linus Torvalds <torvalds@kernel.org>
|
||||
sub rsa2048 2011-09-20 [E]
|
||||
|
||||
Poi, aprite il `PGP pathfinder`_. Nel campo "From", incollate l'impronta
|
||||
digitale della chiave di Linus Torvalds che si vede nell'output qui sopra.
|
||||
Nel campo "to", incollate il key-id della chiave sconosciuta che avete
|
||||
trovato con ``gpg --search``, e poi verificare il risultato:
|
||||
|
||||
- `Finding paths to Linus`_
|
||||
Poi, cercate un percorso affidabile da Linux Torvalds alla chiave che avete
|
||||
trovato con ``gpg --search`` usando la chiave sconosciuta.Per farlo potete usare
|
||||
diversi strumenti come https://github.com/mricon/wotmate,
|
||||
https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, e
|
||||
https://the.earth.li/~noodles/pathfind.html.
|
||||
|
||||
Se trovate un paio di percorsi affidabili è un buon segno circa la validità
|
||||
della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver::
|
||||
@ -948,6 +947,3 @@ fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non
|
||||
sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`).
|
||||
Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso
|
||||
miglioramento rispetto alla cieca fiducia nei keyserver.
|
||||
|
||||
.. _`PGP pathfinder`: https://pgp.cs.uu.nl/
|
||||
.. _`Finding paths to Linus`: https://pgp.cs.uu.nl/paths/79BE3E4300411886/to/C94035C21B4F2AEB.html
|
||||
|
||||
10
Documentation/translations/it_IT/process/maintainer-tip.rst
Normal file
10
Documentation/translations/it_IT/process/maintainer-tip.rst
Normal file
@ -0,0 +1,10 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: Documentation/process/maintainer-tip.rst
|
||||
|
||||
Il tascabile dei sorgenti tip
|
||||
=============================
|
||||
|
||||
.. note:: To be translated
|
||||
13
Documentation/translations/it_IT/process/maintainers.rst
Normal file
13
Documentation/translations/it_IT/process/maintainers.rst
Normal file
@ -0,0 +1,13 @@
|
||||
:Original: Documentation/process/maintainers.rst
|
||||
|
||||
Lista dei manutentori e come inviare modifiche al kernel
|
||||
========================================================
|
||||
|
||||
Questa pagina non verrà tradotta. Fate riferimento alla versione originale in
|
||||
inglese.
|
||||
|
||||
.. note:: La pagina originale usa una direttiva speciale per integrare il file
|
||||
`MAINTAINERS` in sphinx. La parte di quel documento che si potrebbe
|
||||
tradurre contiene comunque informazioni già presenti in
|
||||
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst
|
||||
<it_submittingpatches>`.
|
||||
@ -41,10 +41,10 @@ Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
|
||||
Procedura per sottomettere patch per i sorgenti -stable
|
||||
-------------------------------------------------------
|
||||
|
||||
- Una patch di sicurezza non dovrebbero essere gestite (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>`.
|
||||
|
||||
.. 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>`.
|
||||
|
||||
Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
|
||||
------------------------------------------------------------------------
|
||||
@ -90,9 +90,9 @@ L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento
|
||||
dell'inclusione dei sorgenti principali, si ritiene che non debbano essere
|
||||
incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero
|
||||
fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
|
||||
particolarmente utile se la patch ha bisogno di qualche modifica per essere
|
||||
applicata ad un kernel più vecchio (per esempio, perché nel frattempo l'API è
|
||||
cambiata).
|
||||
particolarmente utile se una patch dev'essere riportata su una versione
|
||||
precedente (per esempio la patch richiede modifiche a causa di cambiamenti di
|
||||
API).
|
||||
|
||||
Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
|
||||
sorgenti principali (per esempio perché è stato necessario un lavoro di
|
||||
@ -167,9 +167,18 @@ Ciclo di una revisione
|
||||
della lista linux-kernel obietta la bontà della patch, sollevando problemi
|
||||
che i manutentori ed i membri non avevano compreso, allora la patch verrà
|
||||
rimossa dalla coda.
|
||||
- Alla fine del ciclo di revisione tutte le patch che hanno ricevuto l'ACK
|
||||
verranno aggiunte per il prossimo rilascio -stable, e successivamente
|
||||
questo nuovo rilascio verrà fatto.
|
||||
- Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
|
||||
un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
|
||||
dai testatori.
|
||||
- Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
|
||||
importanti, alcune patch potrebbero essere modificate o essere scartate,
|
||||
oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate
|
||||
nuove -rc e così via finché non si ritiene che non vi siano più problemi.
|
||||
- Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
|
||||
con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al
|
||||
commit rilascio.
|
||||
- Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
|
||||
patch che erano in coda e sono state verificate.
|
||||
- Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
|
||||
dalla squadra per la sicurezza del kernel, e non passerà per il normale
|
||||
ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
|
||||
@ -186,8 +195,19 @@ Sorgenti
|
||||
- Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
|
||||
trovato in rami distinti per versione al seguente indirizzo:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
|
||||
|
||||
- I rilasci candidati di tutti i kernel stabili possono essere trovati al
|
||||
seguente indirizzo:
|
||||
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
|
||||
|
||||
|
||||
.. warning::
|
||||
I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
|
||||
subirà frequenti modifiche, dunque verrà anche trapiantato spesso.
|
||||
Dovrebbe essere usato solo allo scopo di verifica (per esempio in un
|
||||
sistema di CI)
|
||||
|
||||
Comitato per la revisione
|
||||
-------------------------
|
||||
|
||||
@ -1,16 +0,0 @@
|
||||
.. include:: ../disclaimer-ita.rst
|
||||
|
||||
:Original: :ref:`Documentation/process/submitting-drivers.rst <submittingdrivers>`
|
||||
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>
|
||||
|
||||
.. _it_submittingdrivers:
|
||||
|
||||
Sottomettere driver per il kernel Linux
|
||||
=======================================
|
||||
|
||||
.. note::
|
||||
|
||||
Questo documento è vecchio e negli ultimi anni non è stato più aggiornato;
|
||||
dovrebbe essere aggiornato, o forse meglio, rimosso. La maggior parte di
|
||||
quello che viene detto qui può essere trovato anche negli altri documenti
|
||||
dedicati allo sviluppo. Per questo motivo il documento non verrà tradotto.
|
||||
@ -18,16 +18,18 @@ Questo documento contiene un vasto numero di suggerimenti concisi. Per maggiori
|
||||
dettagli su come funziona il processo di sviluppo del kernel leggete
|
||||
Documentation/translations/it_IT/process/development-process.rst. Leggete anche
|
||||
Documentation/translations/it_IT/process/submit-checklist.rst per una lista di
|
||||
punti da verificare prima di inviare del codice. Se state inviando un driver,
|
||||
allora leggete anche
|
||||
Documentation/translations/it_IT/process/submitting-drivers.rst; per delle patch
|
||||
relative alle associazioni per Device Tree leggete
|
||||
punti da verificare prima di inviare del codice.
|
||||
Per delle patch relative alle associazioni per Device Tree leggete
|
||||
Documentation/translations/it_IT/process/submitting-patches.rst.
|
||||
|
||||
Questa documentazione assume che sappiate usare ``git`` per preparare le patch.
|
||||
Se non siete pratici di ``git``, allora è bene che lo impariate;
|
||||
renderà la vostra vita di sviluppatore del kernel molto più semplice.
|
||||
|
||||
I sorgenti di alcuni sottosistemi e manutentori contengono più informazioni
|
||||
riguardo al loro modo di lavorare ed aspettative. Consultate
|
||||
:ref:`Documentation/translations/it_IT/process/maintainer-handbooks.rst <it_maintainer_handbooks_main>`
|
||||
|
||||
Ottenere i sorgenti attuali
|
||||
---------------------------
|
||||
|
||||
@ -84,11 +86,11 @@ comporti come descritto.
|
||||
|
||||
I manutentori vi saranno grati se scrivete la descrizione della patch in un
|
||||
formato che sia compatibile con il gestore dei sorgenti usato dal kernel,
|
||||
``git``, come un "commit log". Leggete :ref:`it_explicit_in_reply_to`.
|
||||
``git``, come un "commit log". Leggete :ref:`it_the_canonical_patch_format`.
|
||||
|
||||
Risolvete solo un problema per patch. Se la vostra descrizione inizia ad
|
||||
essere lunga, potrebbe essere un segno che la vostra patch necessita d'essere
|
||||
divisa. Leggete :ref:`split_changes`.
|
||||
divisa. Leggete :ref:`it_split_changes`.
|
||||
|
||||
Quando inviate o rinviate una patch o una serie, includete la descrizione
|
||||
completa delle modifiche e la loro giustificazione. Non limitatevi a dire che
|
||||
@ -104,17 +106,28 @@ do frotz" piuttosto che "[This patch] makes xyzzy do frotz" or "[I] changed
|
||||
xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo
|
||||
comportamento.
|
||||
|
||||
Se la patch corregge un baco conosciuto, fare riferimento a quel baco inserendo
|
||||
il suo numero o il suo URL. Se la patch è la conseguenza di una discussione
|
||||
su una lista di discussione, allora fornite l'URL all'archivio di quella
|
||||
discussione; usate i collegamenti a https://lore.kernel.org/ con il
|
||||
``Message-Id``, in questo modo vi assicurerete che il collegamento non diventi
|
||||
invalido nel tempo.
|
||||
Se ci sono delle discussioni, o altre informazioni d'interesse, che fanno
|
||||
riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi
|
||||
riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere
|
||||
quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
|
||||
o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far
|
||||
riferimento ad una discussione precedentemente avvenuta su una lista di
|
||||
discussione, o qualcosa di documentato sul web, da cui poi è nata la patch in
|
||||
questione.
|
||||
|
||||
Tuttavia, cercate di rendere la vostra spiegazione comprensibile anche senza
|
||||
far riferimento a fonti esterne. In aggiunta ai collegamenti a bachi e liste
|
||||
di discussione, riassumente i punti più importanti della discussione che hanno
|
||||
portato alla creazione della patch.
|
||||
Quando volete fare riferimento ad una lista di discussione, preferite il
|
||||
servizio d'archiviazione lore.kernel.org. Per create un collegamento URL è
|
||||
sufficiente usare il campo ``Message-Id``, presente nell'intestazione del
|
||||
messaggio, senza parentesi angolari. Per esempio::
|
||||
|
||||
Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
|
||||
|
||||
Prima d'inviare il messaggio ricordatevi di verificare che il collegamento così
|
||||
creato funzioni e che indirizzi verso il messaggio desiderato.
|
||||
|
||||
Tuttavia, provate comunque a dare una spiegazione comprensibile anche senza
|
||||
accedere alle fonti esterne. Inoltre, riassumente i punti più salienti che hanno
|
||||
condotto all'invio della patch.
|
||||
|
||||
Se volete far riferimento a uno specifico commit, non usate solo
|
||||
l'identificativo SHA-1. Per cortesia, aggiungete anche la breve riga
|
||||
@ -226,10 +239,11 @@ nella vostra patch.
|
||||
|
||||
Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi
|
||||
interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia
|
||||
delle revisioni per scoprire chi si occupa del codice. Lo script
|
||||
scripts/get_maintainer.pl può esservi d'aiuto. Se non riuscite a trovare un
|
||||
manutentore per il sottosistema su cui state lavorando, allora Andrew Morton
|
||||
(akpm@linux-foundation.org) sarà la vostra ultima possibilità.
|
||||
delle revisioni per scoprire chi si occupa del codice. Lo script
|
||||
scripts/get_maintainer.pl può esservi d'aiuto (passategli il percorso alle
|
||||
vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su
|
||||
cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la
|
||||
vostra ultima possibilità.
|
||||
|
||||
Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la
|
||||
vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
|
||||
@ -324,14 +338,19 @@ cosa stia accadendo.
|
||||
|
||||
Assicuratevi di dire ai revisori quali cambiamenti state facendo e di
|
||||
ringraziarli per il loro tempo. Revisionare codice è un lavoro faticoso e che
|
||||
richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche
|
||||
in questo caso, rispondete con educazione e concentratevi sul problema che
|
||||
hanno evidenziato.
|
||||
richiede molto tempo, e a volte i revisori diventano burberi. Tuttavia, anche in
|
||||
questo caso, rispondete con educazione e concentratevi sul problema che hanno
|
||||
evidenziato. Quando inviate una version successiva ricordatevi di aggiungere un
|
||||
``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando
|
||||
le differenze rispetto a sottomissioni precedenti (vedere
|
||||
:ref:`it_the_canonical_patch_format`).
|
||||
|
||||
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_resend_reminders:
|
||||
|
||||
Non scoraggiatevi - o impazientitevi
|
||||
------------------------------------
|
||||
|
||||
@ -504,7 +523,8 @@ Utilizzare Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: e Fixes:
|
||||
L'etichetta Reported-by da credito alle persone che trovano e riportano i bachi
|
||||
e si spera che questo possa ispirarli ad aiutarci nuovamente in futuro.
|
||||
Rammentate che se il baco è stato riportato in privato, dovrete chiedere il
|
||||
permesso prima di poter utilizzare l'etichetta Reported-by.
|
||||
permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va
|
||||
usata per i bachi, dunque non usatela per richieste di nuove funzionalità.
|
||||
|
||||
L'etichetta Tested-by: indica che la patch è stata verificata con successo
|
||||
(su un qualche sistema) dalla persona citata. Questa etichetta informa i
|
||||
@ -574,6 +594,8 @@ previste per i kernel stabili, e nemmeno dalla necessità di aggiungere
|
||||
in copia conoscenza stable@vger.kernel.org su tutte le patch per
|
||||
suddetti kernel.
|
||||
|
||||
.. _it_the_canonical_patch_format:
|
||||
|
||||
Il formato canonico delle patch
|
||||
-------------------------------
|
||||
|
||||
@ -719,6 +741,8 @@ messe correttamente oltre la riga.::
|
||||
|
||||
Maggiori dettagli sul formato delle patch nei riferimenti qui di seguito.
|
||||
|
||||
.. _it_backtraces:
|
||||
|
||||
Aggiungere i *backtrace* nei messaggi di commit
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user