| /Documentation/process/ |
| D | adding-syscalls.rst | 4 Adding a New System Call
7 This document describes what's involved in adding a new system call to the
15 The first thing to consider when adding a new system call is whether one of
22 object, it may make more sense to create a new filesystem or device. This
23 also makes it easier to encapsulate the new functionality in a kernel module
26 - If the new functionality involves operations where the kernel notifies
27 userspace that something has happened, then returning a new file
35 - If you're just exposing runtime system information, a new node in sysfs
44 this option is best for when the new function is closely analogous to
45 existing :manpage:`fcntl(2)` functionality, or the new functionality is very simple
[all …]
|
| D | maintainer-soc-clean-dts.rst | 18 new ``make dtbs_check W=1`` warnings. Warnings in a new board DTS, which are
19 results of issues in an included DTSI file, are considered existing, not new
21 out any new warnings.
23 If a commit introducing new warnings gets accepted somehow, the resulting
|
| D | submit-checklist.rst | 31 1) Any new or modified ``CONFIG`` options do not muck up the config menu and
35 2) All new ``Kconfig`` options have help text.
47 2) All new ``/proc`` entries are documented under ``Documentation/``
49 3) All new kernel boot parameters are documented in
52 4) All new module parameters are documented with ``MODULE_PARM_DESC()``
54 5) All new userspace interfaces are documented in ``Documentation/ABI/``.
89 d) Any Documentation/ changes build successfully without new warnings/errors.
128 If the new code is substantial, addition of subsystem-specific fault
|
| /Documentation/mm/ |
| D | page_migration.rst | 19 a new memory policy via mbind(). The pages of a process can also be relocated
34 nearer to the new processor. The kernel itself only provides
47 a new cpuset then also all its pages are moved with it so that the
78 how to allocate the correct new folio given the old folio.
82 the new folio for each folio that is considered for moving.
98 3. Lock the new page that we want to move to. It is locked so that accesses to
116 8. The new page is prepped with some settings from the old page so that
117 accesses to the new page will discover a page with the correct settings.
119 9. The radix tree is changed to point to the new page.
122 reference is gone. A reference to the new page is established because
[all …]
|
| D | mmu_notifier.rst | 14 B) a page table entry is updated to point to a new page (COW, write fault
25 - set page table entry to point to new page
28 the new pte/pmd value then you can break memory model like C11 or C++11 for
53 CPU-thread-0 {COW_step1: {update page table to point to new page for addrA}}
54 CPU-thread-1 {COW_step1: {update page table to point to new page for addrB}}
62 CPU-thread-2 {write to addrA which is a write to new page}
70 CPU-thread-3 {write to addrB which is a write to new page}
86 DEV-thread-2 {read addrB from new page}
89 notification to invalidate the secondary TLB, the device see the new value for
90 addrB before seeing the new value for addrA. This break total memory ordering
[all …]
|
| /Documentation/admin-guide/ |
| D | binderfs.rst | 8 located in a new binderfs instance are independent of binder devices located in
9 other binderfs instances. Mounting a new binderfs instance makes it possible
20 at which point a new instance of binderfs will show up at ``/dev/binderfs``.
24 create a new and separate instance from all other binderfs mounts. This is
47 To allocate a new binder device in a binderfs instance a request needs to be
53 tell the kernel which name the new binder device should get. By default a name
58 binder_device`` with the name to the kernel it will allocate a new binder
59 device and return the major and minor number of the new device in the struct
61 dynamically.). After the `ioctl() <ioctl_>`_ returns there will be a new
|
| /Documentation/security/ |
| D | IMA-templates.rst | 19 a new template is defined, the functions that generate and display
20 the measurements list would include the code for handling a new format
25 definition of two new data structures: a template descriptor, to determine
30 a new data type, developers define the field identifier and implement
32 measurement entries. Defining a new template descriptor requires
40 (new function defined within the patches for the new template management
41 mechanism) to generate a new measurement entry by using the template
44 It is during this phase that the advantages of the new architecture are
61 ``('<identifier>': description)``, that can be used to define new template
110 - register a new template descriptor with custom format through the kernel
|
| /Documentation/virt/kvm/ |
| D | review-checklist.rst | 12 3. If the patch introduces or modifies a new userspace API:
16 4. New state must include support for save/restore.
18 5. New features must default to off (userspace should explicitly request them).
21 6. New cpu features should be exposed via KVM_GET_SUPPORTED_CPUID2
36 11. New guest visible features must either be documented in a hardware manual
|
| /Documentation/translations/zh_CN/core-api/ |
| D | rbtree.rst | 112 struct rb_node **new = &(root->rb_node), *parent = NULL;
114 /* Figure out where to put new node */
115 while (*new) {
116 struct mytype *this = container_of(*new, struct mytype, node);
119 parent = *new;
121 new = &((*new)->rb_left);
123 new = &((*new)->rb_right);
128 /* Add new node and rebalance tree. */
129 rb_link_node(&data->node, parent, new);
153 void rb_replace_node(struct rb_node *old, struct rb_node *new,
[all …]
|
| /Documentation/security/keys/ |
| D | trusted-encrypted.rst | 5 Trusted and Encrypted Keys are two new key types added to the existing kernel
6 key ring service. Both of these new types are variable length symmetric keys,
80 verifications match. A loaded Trusted Key can be updated with new
81 (future) PCR values, so keys are easily migrated to new PCR values,
133 New keys are created from random numbers. They are encrypted/decrypted using
170 for encryption/decryption. New keys are created either from kernel-generated
207 keyctl add trusted name "new keylen [options]" ring
222 migratable= 0|1 indicating permission to reseal to new PCR values,
235 TPM_STORED_DATA format. The key length for new keys are always in bytes.
244 keyctl add trusted name "new keylen" ring
[all …]
|
| /Documentation/core-api/ |
| D | rbtree.rst | 59 Creating a new rbtree
110 new node, then inserting the node and rebalancing ("recoloring") the tree.
113 location of the pointer on which to graft the new node. The new node also
120 struct rb_node **new = &(root->rb_node), *parent = NULL;
122 /* Figure out where to put new node */
123 while (*new) {
124 struct mytype *this = container_of(*new, struct mytype, node);
127 parent = *new;
129 new = &((*new)->rb_left);
131 new = &((*new)->rb_right);
[all …]
|
| /Documentation/devicetree/bindings/arm/samsung/ |
| D | samsung-soc.yaml | 13 Guidelines for new compatibles for SoC blocks/components.
14 When adding new compatibles in new bindings, use the format::
33 # Legacy compatibles with wild-cards - list cannot grow with new bindings:
|
| /Documentation/ |
| D | atomic_t.txt | 279 int atomic_cmpxchg(atomic_t *ptr, int old, int new);
280 bool atomic_try_cmpxchg(atomic_t *ptr, int *oldp, int new);
285 bool atomic_try_cmpxchg(atomic_t *ptr, int *oldp, int new)
288 ret = atomic_cmpxchg(ptr, old, new);
296 int atomic_cmpxchg(atomic_t *ptr, int old, int new)
298 (void)atomic_try_cmpxchg(ptr, &old, new);
306 new = func(old); new = func(old);
307 tmp = atomic_cmpxchg(&v, old, new); } while (!atomic_try_cmpxchg(&v, &old, new));
333 new = func(old);
334 } while (!atomic_try_cmpxchg(&v, &old, new));
[all …]
|
| /Documentation/arch/sh/ |
| D | new-machine.rst | 4 Adding a new board to LinuxSH
10 for new boards to the LinuxSH port under the new 2.5 and 2.6 kernels. This
14 1. New Directory Structure
17 The first thing to note is the new directory structure. Under 2.4, most
20 include/asm-sh/. For the new kernel, things are broken out by board type,
89 2. Adding a New Board
103 After you have setup your new arch/sh/boards/ directory, remember that you
145 Our new imaginary board will also have to tie into the machvec in order for it
167 Adding a new machine is relatively trivial (using vapor as an example):
173 - add a new file include/asm-sh/vapor.h which contains prototypes for
[all …]
|
| /Documentation/filesystems/xfs/ |
| D | xfs-maintainer-entry-profile.rst | 37 write new code, documentation, and tests.
65 on new tests for new features, and making sure that developers and
81 The release manager is not expected to work on new feature patchsets.
126 When possible, a new regression test case should be written for
129 - Authors of new feature patchsets must ensure that fstests will have
130 appropriate functional and input corner-case test cases for the new
133 - When implementing a new feature, it is strongly suggested that the
141 * **How** will this new feature work? This should touch on major data
145 * **What** userspace interfaces are necessary to build off of the new
149 problems laid out in the design document without causing new
[all …]
|
| /Documentation/userspace-api/ |
| D | unshare.rst | 4 This document describes the new system call, unshare(). The document
48 shared resources without creating a new process. unshare() is a natural
56 where creating a new process to control sharing/unsharing of process
58 when creating a new process using fork or clone, unshare() can benefit
100 stable code to implement a new feature that may not get exercised
103 the benefits of this new feature can exceed its cost.
118 new context flags without requiring a rebuild of old applications.
119 If and when new context flags are added, unshare() design should allow
137 when a new process is created using fork(2), while other parts,
143 shared execution context without creating a new process.
[all …]
|
| /Documentation/networking/device_drivers/fddi/ |
| D | skfp.rst | 144 changed in SMT version v2.82. With this new SMT version, the yellow
163 New features:
166 - new pci dma interface
170 New features:
175 New features:
191 New features:
197 New features:
209 - New SMT module included, changing LED functionality
221 New features:
233 New features:
|
| /Documentation/devicetree/bindings/soc/renesas/ |
| D | renesas-soc.yaml | 14 Guidelines for new compatibles for SoC blocks/components.
15 When adding new compatibles in new bindings, use the format::
21 When adding new compatibles to existing bindings, use the format in the
44 # New compatibles are not allowed.
58 # component are OK. New compatibles are allowed.
|
| /Documentation/filesystems/ |
| D | sharedsubtree.rst | 99 the new mount at /tmp becomes a shared mount and it is a replica of
174 Now any process that clones off a new namespace will have a
192 A new process can clone off a new namespace. And mark some part
385 1. 'A' is a shared mount and 'B' is a shared mount. A new mount 'C'
387 mounted on mount 'B' at dentry 'b'. Also new mount 'C1', 'C2', 'C3' ...
389 propagates to. A new propagation tree containing 'C1',..,'Cn' is
394 2. 'A' is a private mount and 'B' is a shared mount. A new mount 'C'
396 mounted on mount 'B' at dentry 'b'. Also new mount 'C1', 'C2', 'C3' ...
398 propagates to. A new propagation tree is set containing all new mounts
402 3. 'A' is a slave mount of mount 'Z' and 'B' is a shared mount. A new
[all …]
|
| /Documentation/arch/x86/x86_64/ |
| D | fred.rst | 10 The FRED architecture defines simple new transitions that change
23 The new transitions defined by the FRED architecture are FRED event
31 In addition to these transitions, the FRED architecture defines a new
34 not use the new FRED transitions.
61 FRED allows explicit unblock of NMI with new event return instructions
91 stack. If higher, the CPU switches to a new event stack specified by
92 the MSR of the new stack level, i.e., MSR_IA32_FRED_RSP[123].
|
| /Documentation/translations/zh_TW/arch/arm/ |
| D | kernel_user_helpers.txt | 168 int old, new;
172 new = old + val;
173 } while(__kuser_cmpxchg(old, new, ptr));
175 return new;
266 int64_t old, new;
270 new = old + val;
271 } while(__kuser_cmpxchg64(&old, &new, ptr));
273 return new;
|
| /Documentation/translations/zh_CN/arch/arm/ |
| D | kernel_user_helpers.txt | 168 int old, new;
172 new = old + val;
173 } while(__kuser_cmpxchg(old, new, ptr));
175 return new;
266 int64_t old, new;
270 new = old + val;
271 } while(__kuser_cmpxchg64(&old, &new, ptr));
273 return new;
|
| /Documentation/arch/arm/ |
| D | kernel_user_helpers.rst | 32 use new instructions for other purpose.
34 New helpers may be added over time, so an older kernel may be missing some
155 int old, new;
159 new = old + val;
160 } while(__kuser_cmpxchg(old, new, ptr));
162 return new;
251 int64_t old, new;
255 new = old + val;
256 } while(__kuser_cmpxchg64(&old, &new, ptr));
258 return new;
|
| /Documentation/devicetree/bindings/arm/ |
| D | qcom-soc.yaml | 13 Guidelines for new compatibles for SoC blocks/components.
14 When adding new compatibles in new bindings, use the format::
20 When adding new compatibles to existing bindings, use the format in the
38 # but do not add completely new entries to these:
58 # Legacy compatibles with wild-cards - list cannot grow with new bindings:
|
| /Documentation/devicetree/bindings/ |
| D | ABI.rst | 14 don't result in breakage. For instance, if a new property is added,
18 new. These guidelines aren't new, but they desperately need to be
27 in the future, we can create a new compatible string. See I.
|