| /linux/Documentation/filesystems/ |
| H A D | idmappings.rst | 1 .. SPDX-License-Identifier: GPL-2.0
12 ------------
16 in userspace is::
20 ``u`` indicates the first element in the upper idmapset ``U`` and ``k``
21 indicates the first element in the lower idmapset ``K``. The ``r`` parameter
24 we're talking about an id in the upper or lower idmapset.
26 To see what this looks like in practice, let's take the following idmapping::
32 u22 -> k10000
33 u23 -> k10001
34 u24 -> k10002
[all …]
|
| /linux/Documentation/process/ |
| H A D | 1.Intro.rst | 7 -----------------
9 The rest of this section covers the scope of the kernel development process
11 encounter there. There are a great many reasons why kernel code should be
12 merged into the official ("mainline") kernel, including automatic
13 availability to users, community support in many forms, and the ability to
14 influence the direction of kernel development. Code contributed to the
15 Linux kernel must be made available under a GPL-compatible license.
17 :ref:`development_process` introduces the development process, the kernel
18 release cycle, and the mechanics of the merge window. The various phases in
21 with kernel development are encouraged to track down and fix bugs as an
[all …]
|
| H A D | howto.rst | 3 HOWTO do Linux kernel development
6 This is the be-all, end-all document on this topic. It contains
7 instructions on how to become a Linux kernel developer and how to learn
8 to work with the Linux kernel development community. It tries to not
9 contain anything related to the technical aspects of kernel programming,
10 but will help point you in the right direction for that.
12 If anything in this document becomes out of date, please send in patches
18 ------------
20 So, you want to learn how to become a Linux kernel developer? Or you
27 The kernel is written mostly in C, with some architecture-dependent
[all …]
|
| H A D | stable-api-nonsense.rst | 3 The Linux Kernel Driver Interface
8 Greg Kroah-Hartman <greg@kroah.com>
11 kernel interface, nor does it have a stable kernel interface**.
15 Please realize that this article describes the **in kernel** interfaces, not
16 the kernel to userspace interfaces.
18 The kernel to userspace interface is the one that application programs use,
21 kernel that still work just fine on the latest 2.6 kernel release.
27 -----------------
28 You think you want a stable kernel interface, but you really do not, and
30 you get that only if your driver is in the main kernel tree. You also
[all …]
|
| H A D | 2.Process.rst | 6 Linux kernel development in the early 1990's was a pretty loose affair,
8 user base in the millions and with some 2,000 developers involved over the
9 course of one year, the kernel has since had to evolve a number of
11 how the process works is required in order to be an effective part of it.
14 ---------------
16 The Linux kernel uses a loosely time-based, rolling release development
17 model. A new major kernel release (which we will call, as an example, 9.x)
24 .. [1] Strictly speaking, the Linux kernel does not use semantic versioning
34 community) is merged into the mainline kernel. The bulk of changes for a
41 and staged ahead of time. How that process works will be described in
[all …]
|
| H A D | 4.Coding.rst | 6 While there is much to be said for a solid and community-oriented design
7 process, the proof of any kernel development project is in the resulting
13 number of ways in which kernel developers can go wrong. Then the focus
14 will shift toward doing things right and the tools which can help in that
19 ---------
24 The kernel has long had a standard coding style, described in
25 :ref:`Documentation/process/coding-style.rst <codingstyle>`. For much of
26 that time, the policies described in that file were taken as being, at most,
27 advisory. As a result, there is a substantial amount of code in the kernel
29 leads to two independent hazards for kernel developers.
[all …]
|
| H A D | applying-patches.rst | 3 Applying Patches To The Linux Kernel
11 This document is obsolete. In most cases, rather than using ``patch``
14 A frequently asked question on the Linux Kernel Mailing List is how to apply
15 a patch to the kernel or, more specifically, what base kernel a patch for
19 In addition to explaining how to apply and revert patches, a brief
20 description of the different kernel trees (and examples of how to apply
33 should both be present in the patch file metadata or be possible to deduce
41 (or patch) file and makes the changes to the source tree described in it.
43 Patches for the Linux kernel are generated relative to the parent directory
44 holding the kernel source dir.
[all …]
|
| H A D | cve.rst | 8 regards to the kernel project, and CVE numbers were very often assigned
9 in inappropriate ways and for inappropriate reasons. Because of this,
10 the kernel development community has tended to avoid them. However, the
13 outside of the kernel community has made it clear that the kernel
16 The Linux kernel developer team does have the ability to assign CVEs for
17 potential Linux kernel security issues. This assignment is independent
18 of the :doc:`normal Linux kernel security bug reporting
19 process<../process/security-bugs>`.
21 A list of all assigned CVEs for the Linux kernel can be found in the
22 archives of the linux-cve mailing list, as seen on
[all …]
|
| H A D | 3.Early-stage.rst | 3 Early-stage planning
6 When contemplating a Linux kernel development project, it can be tempting
7 to jump right in and start coding. As with any significant project,
9 line of code is written. Some time spent in early planning and
14 ----------------------
16 Like any engineering project, a successful kernel enhancement starts with a
17 clear description of the problem to be solved. In some cases, this step is
19 example. In others, though, it is tempting to confuse the real problem
24 by excessive latency in the system. The solution they arrived at was a
25 kernel module intended to hook into the Linux Security Module (LSM)
[all …]
|
| H A D | adding-syscalls.rst | 7 This document describes what's involved in adding a new system call to the
8 Linux kernel, over and above the normal submission advice in
9 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`.
13 ------------------------
18 kernel, there are other possibilities -- choose what fits best for your
21 - If the operations involved can be made to look like a filesystem-like
23 also makes it easier to encapsulate the new functionality in a kernel module
24 rather than requiring it to be built into the main kernel.
26 - If the new functionality involves operations where the kernel notifies
30 - However, operations that don't map to
[all …]
|
| /linux/Documentation/arch/arm/ |
| H A D | booting.rst | 9 The following documentation is relevant to 2.4.18-rmk6 and beyond.
11 In order to boot ARM Linux, you require a boot loader, which is a small
12 program that runs before the main kernel. The boot loader is expected
13 to initialise various devices, and eventually call the Linux kernel,
14 passing information to the kernel.
22 4. Setup the kernel tagged list.
24 6. Call the kernel image.
28 ---------------------------
36 kernel will use for volatile data storage in the system. It performs
37 this in a machine dependent manner. (It may use internal algorithms
[all …]
|
| /linux/Documentation/admin-guide/ |
| H A D | README.rst | 3 Linux kernel release 6.x <http://kernel.org/>
8 kernel, and what to do if something goes wrong.
11 --------------
14 Linus Torvalds with assistance from a loosely-knit team of hackers across
17 It has all the features you would expect in a modern fully-fledged Unix,
19 loading, shared copy-on-write executables, proper memory management,
22 It is distributed under the GNU General Public License v2 - see the
26 -----------------------------
28 Although originally developed first for 32-bit x86-based PCs (386 or higher),
31 IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64 Xtensa, and
[all …]
|
| H A D | tainted-kernels.rst | 2 ---------------
4 The kernel will mark itself as 'tainted' when something occurs that might be
6 most of the time it's not a problem to run a tainted kernel; the information is
8 cause might be the event that got the kernel tainted. That's why bug reports
10 problems with an untainted kernel.
12 Note the kernel will remain tainted even after you undo what caused the taint
13 (i.e. unload a proprietary kernel module), to indicate the kernel remains not
14 trustworthy. That's also why the kernel will print the tainted state when it
15 notices an internal problem (a 'kernel bug'), a recoverable error
16 ('kernel oops') or a non-recoverable error ('kernel panic') and writes debug
[all …]
|
| /linux/Documentation/arch/x86/ |
| H A D | pti.rst | 1 .. SPDX-License-Identifier: GPL-2.0
11 countermeasure against attacks on the shared user/kernel address
16 the kernel is entered via syscalls, interrupts or exceptions, the
17 page tables are switched to the full "kernel" copy. When the system
20 The userspace page tables contain only a minimal amount of kernel
21 data: only what is needed to enter/exit the kernel such as the
25 comments in pti.c).
27 This approach helps to ensure that side-channel attacks leveraging
30 time. Once enabled at compile-time, it can be disabled at boot with
31 the 'nopti' or 'pti=' kernel parameters (see kernel-parameters.txt).
[all …]
|
| H A D | boot.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 On the x86 platform, the Linux kernel uses a rather complicated boot
9 well as the desire in the early days to have the kernel itself be a
11 expectations in the PC industry caused by the effective demise of
12 real-mode DOS as a mainstream operating system.
20 Protocol 2.00 (Kernel 1.3.73) Added bzImage and initrd support, as
22 boot loader and the kernel. setup.S made relocatable,
26 Protocol 2.01 (Kernel 1.3.76) Added a heap overrun warning.
28 Protocol 2.02 (Kernel 2.4.0-test3-pre3) New command line protocol.
31 safe for systems which use the EBDA from SMM or 32-bit
[all …]
|
| /linux/include/uapi/linux/ |
| H A D | dm-log-userspace.h | 1 /* SPDX-License-Identifier: LGPL-2.0+ WITH Linux-syscall-note */
3 * Copyright (C) 2006-2009 Red Hat, Inc.
12 #include <linux/dm-ioctl.h> /* For DM_UUID_LEN */
15 * The device-mapper userspace log module consists of a kernel component and
16 * a user-space component. The kernel component implements the API defined
17 * in dm-dirty-log.h. Its purpose is simply to pass the parameters and
18 * return values of those API functions between kernel and user-space.
20 * Below are defined the 'request_types' - DM_ULOG_CTR, DM_ULOG_DTR, etc.
21 * These request types represent the different functions in the device-mapper
22 * dirty log API. Each of these is described in more detail below.
[all …]
|
| /linux/Documentation/security/ |
| H A D | self-protection.rst | 2 Kernel Self-Protection
5 Kernel self-protection is the design and implementation of systems and
6 structures within the Linux kernel to protect against security flaws in
7 the kernel itself. This covers a wide range of issues, including removing
9 and actively detecting attack attempts. Not all topics are explored in
13 In the worst-case scenario, we assume an unprivileged local attacker
14 has arbitrary read and write access to the kernel's memory. In many
16 but with systems in place that defend against the worst case we'll
18 still be kept in mind, is protecting the kernel against a _privileged_
21 kernel modules.)
[all …]
|
| /linux/Documentation/ABI/testing/ |
| H A D | sysfs-devices-system-cpu | 2 Date: pre-git history
3 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
7 Individual CPU attributes are contained in subdirectories
8 named by the kernel's logical CPU number, e.g.:
18 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
19 Description: CPU topology files that describe kernel limits related to
22 kernel_max: the maximum cpu index allowed by the kernel
27 kernel configuration (kernel_max above).
34 present: cpus that have been identified as being present in
37 See Documentation/admin-guide/cputopology.rst for more information.
[all …]
|
| H A D | sysfs-kernel-mm-damon | 1 what: /sys/kernel/mm/damon/
3 Contact: SeongJae Park <sj@kernel.org>
6 please refer to Documentation/admin-guide/mm/damon/index.rst.
8 What: /sys/kernel/mm/damon/admin/
10 Contact: SeongJae Park <sj@kernel.org>
14 What: /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds
16 Contact: SeongJae Park <sj@kernel.org>
19 named '0' to 'N-1' under the kdamonds/ directory.
21 What: /sys/kernel/mm/damon/admin/kdamonds/<K>/state
23 Contact: SeongJae Park <sj@kernel.org>
[all …]
|
| /linux/Documentation/doc-guide/ |
| H A D | kernel-doc.rst | 1 .. title:: Kernel-doc comments
4 Writing kernel-doc comments
7 The Linux kernel source files may contain structured documentation
8 comments in the kernel-doc format to describe the functions, types
9 and design of the code. It is easier to keep documentation up-to-date
10 when it is embedded in source files.
12 .. note:: The kernel-doc format is deceptively similar to javadoc,
13 gtk-doc or Doxygen, yet distinctively different, for historical
14 reasons. The kernel source contains tens of thousands of kernel-doc
17 .. note:: kernel-doc does not cover Rust code: please see
[all …]
|
| /linux/Documentation/bpf/ |
| H A D | bpf_devel_QA.rst | 10 Documentation/process/submitting-patches.rst. This document only describes
20 Q: How do I report bugs for BPF kernel code?
21 --------------------------------------------
22 A: Since all BPF kernel development as well as bpftool and iproute2 BPF
23 loader development happens through the bpf kernel mailing list,
27 bpf@vger.kernel.org
32 maintainers to Cc (from kernel ``MAINTAINERS`` file):
34 * Alexei Starovoitov <ast@kernel.org>
37 In case a buggy commit has already been identified, make sure to keep
38 the actual commit authors in Cc as well for the report. They can
[all …]
|
| /linux/arch/riscv/ |
| H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0-only
4 # see Documentation/kbuild/kconfig-language.rst.
65 # clang >= 17: https://github.com/llvm/llvm-project/commit/62fa708ceb027713b386c7e0efda994f8bdc27e2
236 # -Zsanitizer=shadow-call-stack flag.
246 depends on $(cc-option,-fpatchable-function-entry=8)
250 def_bool $(cc-option,-fsanitize=shadow-call-stack)
251 …# https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a484e843e6eeb51f0cb7b8819e50da6d2444…
252 depends on $(ld-option,--no-relax-gp)
254 # https://github.com/llvm/llvm-project/commit/bbc0f99f3bc96f1db16f649fc21dd18e5b0918f6
257 # https://github.com/llvm/llvm-project/commit/1df5ea29b43690b6622db2cad7b745607ca4de6a
[all …]
|
| /linux/arch/arm/ |
| H A D | Kconfig | 1 # SPDX-License-Identifier: GPL-2.0
47 # https://github.com/llvm/llvm-project/commit/d130f402642fba3d065aacb506cb061c899558de
164 The ARM series is a line of low-power-consumption RISC chip designs
166 handhelds such as the Compaq IPAQ. ARM-based PCs are no longer
167 manufactured, but legacy ARM-based PC hardware remains popular in
175 relocations. The combined range is -/+ 256 MiB, which is usually
268 Patch phys-to-virt and virt-to-phys translation functions at
270 kernel in system memory.
272 This can only be used with non-XIP MMU kernels where the base
276 this feature (eg, building a kernel for a single machine) and
[all …]
|
| /linux/lib/ |
| H A D | Kconfig.debug | 1 # SPDX-License-Identifier: GPL-2.0-only
2 menu "Kernel hacking"
18 The behavior is also controlled by the kernel command line
19 parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst
26 in task context) or a caller "processor id" (if not in task context)
35 no option to enable/disable at the kernel command line parameter or
39 bool "Show build ID information in stacktraces"
42 Selecting this option adds build ID information for symbols in
47 kernel module where the function is located.
50 int "Default console loglevel (1-15)"
[all …]
|
| /linux/Documentation/translations/it_IT/process/ |
| H A D | 1.Intro.rst | 1 .. include:: ../disclaimer-ita.rst
12 ------------------
14 Il resto di questa sezione riguarda il processo di sviluppo del kernel e
17 per il kernel debba essere incorporato nel kernel ufficiale, fra le quali:
18 disponibilità immediata agli utilizzatori, supporto della comunità in
20 del kernel.
21 Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto
22 una licenza GPL-compatibile.
25 il ciclo di rilascio del kernel, ed i meccanismi della finestra
28 liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare
[all …]
|