Searched +full:in +full:- +full:tree (Results 1 – 25 of 780) sorted by relevance
12345678910>>...32
| /Documentation/core-api/ |
| D | maple_tree.rst | 1 .. SPDX-License-Identifier: GPL-2.0+
5 Maple Tree
13 The Maple Tree is a B-Tree data type which is optimized for storing
14 non-overlapping ranges, including ranges of size 1. The tree was designed to
17 entry in a cache-efficient manner. The tree can also be put into an RCU-safe
22 The Maple Tree maintains a small memory footprint and was designed to use
24 use the normal API. An :ref:`maple-tree-advanced-api` exists for more complex
25 scenarios. The most important usage of the Maple Tree is the tracking of the
28 The Maple Tree can store values between ``0`` and ``ULONG_MAX``. The Maple
29 Tree reserves values with the bottom two bits set to '10' which are below 4096
[all …]
|
| D | rbtree.rst | 2 Red-black Trees (rbtree) in Linux
9 What are red-black trees, and what are they for?
10 ------------------------------------------------
12 Red-black trees are a type of self-balancing binary search tree, used for
16 be easily traversed in order, and must be tuned for a specific size and
19 Red-black trees are similar to AVL trees, but provide faster real-time bounded
21 three rotations, respectively, to balance the tree), with slightly slower
26 There are a number of red-black trees in use in the kernel.
29 The high-resolution timer code uses an rbtree to organize outstanding
30 timer requests. The ext3 filesystem tracks directory entries in a
[all …]
|
| /Documentation/devicetree/ |
| D | of_unittest.rst | 1 .. SPDX-License-Identifier: GPL-2.0
13 is attached to the live tree dynamically, independent of the machine's
18 (1) Documentation/devicetree/usage-model.rst
23 from the unflattened device tree data structure. This interface is used by
24 most of the device drivers in various use cases.
41 The EXPECT messages result in very noisy console messages that are difficult
45 from 'scripts/dtc/of_unittest_expect --help'.
48 3. Test-data
51 The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
52 the test data required for executing the unit tests automated in
[all …]
|
| D | changesets.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 in the live tree in such a way that either the full set of changes
10 through applying the changeset, then the tree will be rolled back to the
14 When a changeset is applied, all of the changes get applied to the tree
16 receiver sees a complete and consistent state of the tree when it
21 1. of_changeset_init() - initializes a changeset
23 2. A number of DT tree change calls, of_changeset_attach_node(),
26 a set of changes. No changes to the active tree are made at this point.
27 All the change operations are recorded in the of_changeset 'entries'
30 3. of_changeset_apply() - Apply the changes to the tree. Either the
[all …]
|
| D | dynamic-resolution-notes.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 This document describes the implementation of the in-kernel
8 DeviceTree resolver, residing in drivers/of/resolver.c
11 ----------------------
13 The resolver is given as an input an arbitrary tree compiled with the
17 In sequence the resolver works by the following steps:
19 1. Get the maximum device tree phandle value from the live tree + 1.
20 2. Adjust all the local phandles of the tree to resolve by that amount.
23 4. For each property in the __fixups__ node locate the node it references
24 in the live tree. This is the label used to tag the node.
[all …]
|
| D | usage-model.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 The Linux usage model for device tree data
11 This article describes how Linux uses the device tree. An overview of
12 the device tree data format can be found on the device tree usage page
17 The "Open Firmware Device Tree", or simply Devicetree (DT), is a data
23 Structurally, the DT is a tree, or acyclic graph with named nodes, and
26 links from one node to another outside of the natural tree structure.
29 is defined for how data should appear in the tree to describe typical
41 already being enumerated in existing systems.
44 ----------
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-firmware-ofw | 5 When using OpenFirmware or a Flattened Device Tree to enumerate
6 hardware, the device tree structure will be exposed in this
9 It is possible for multiple device-tree directories to exist.
10 Some device drivers use a separate detached device tree which
11 have no attachment to the system tree and will appear in a
15 path directly, but instead should follow /proc/device-tree
17 in the future, but the symlink is the stable ABI.
19 The /proc/device-tree symlink replaces the devicetree /proc
24 hierarchy of directories, one per device tree node. The
27 in the directory. The contents of each file is the exact
[all …]
|
| D | sysfs-devices | 3 Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
5 The /sys/devices tree contains a snapshot of the
6 internal state of the kernel device tree. Devices will
9 devices within this tree will change.
11 Please do not rely on the format of this tree because of
12 this. If a program wishes to find different things in
13 the tree, please use the /sys/class structure and rely
15 within the /sys/devices tree of the individual devices.
17 devices being added and removed from this tree to find
25 udev <linux-hotplug-devel@lists.sourceforge.net>
|
| /Documentation/arch/powerpc/ |
| D | bootwrapper.rst | 12 The boot wrapper can be found in the arch/powerpc/boot/ directory. The
13 Makefile in that directory has targets for all the available image types.
17 others. U-Boot is typically found on embedded PowerPC hardware, but there
21 The boot wrapper is built from the makefile in arch/powerpc/boot/Makefile and
23 image. The details of the build system is discussed in the next section.
28 U-Boot (for versions that don't understand the device
29 tree). This image embeds a device tree blob inside
30 the image. The boot wrapper, kernel and device tree
31 are all embedded inside the U-Boot uImage file format
34 tree before jumping into the kernel.
[all …]
|
| D | booting.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 ------------------
9 bootloader <-> kernel interfaces, in order to avoid the degeneration that had
12 this scheme, but no new board support will be accepted in the main tree that
13 doesn't follow them properly. In addition, since the advent of the arch/powerpc
14 merged architecture for ppc32 and ppc64, new 32-bit platforms and 32-bit
18 The main requirement that will be defined in more detail below is the presence
19 of a device-tree whose format is defined after Open Firmware specification.
20 However, in order to make life easier to embedded board vendors, the kernel
21 doesn't require the device-tree to represent every device in the system and only
[all …]
|
| /Documentation/filesystems/ext4/ |
| D | ifork.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 ------------------------------
7 storage in ``inode.i_block`` can be used in different ways. In general,
14 The target of a symbolic link will be stored in this field if the target
21 In ext2/3, file block numbers were mapped to logical block numbers by
22 means of an (up to) three level 1-1 block map. To find the logical block
43 Extent Tree
46 In ext4, the file to logical block map has been replaced with an extent
47 tree. Under the old scheme, allocating a contiguous run of 1,000 blocks
51 very large files with a single extent, at a considerable reduction in
[all …]
|
| D | verity.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 ------------
6 ext4 supports fs-verity, which is a filesystem feature that provides
7 Merkle tree based hashing for individual readonly files. Most of
8 fs-verity is common to all filesystems that support it; see
10 fs-verity documentation. However, the on-disk layout of the verity
11 metadata is filesystem-specific. On ext4, the verity metadata is
12 stored after the end of the file data itself, in the following format:
14 - Zero-padding to the next 65536-byte boundary. This padding need not
15 actually be allocated on-disk, i.e. it may be a hole.
[all …]
|
| /Documentation/arch/arm/google/ |
| D | chromebook-boot-flow.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 Most recent Chromebooks that use device tree are using the opensource
10 is up to depthcharge_ to pick the right device tree from the `FIT Image`_ and
13 The scheme that depthcharge_ uses to pick the device tree takes into account
16 - Board name, specified at depthcharge_ compile time. This is $(BOARD) below.
17 - Board revision number, determined at runtime (perhaps by reading GPIO
19 - SKU number, read from GPIO strappings at boot time. This is $(SKU) below.
23 - google,$(BOARD)-rev$(REV)-sku$(SKU)
24 - google,$(BOARD)-rev$(REV)
25 - google,$(BOARD)-sku$(SKU)
[all …]
|
| /Documentation/mm/ |
| D | ksm.rst | 5 KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y,
6 added to the Linux kernel in 2.6.32. See ``mm/ksm.c`` for its implementation,
9 The userspace interface of KSM is described in Documentation/admin-guide/mm/ksm.rst
15 --------
17 .. kernel-doc:: mm/ksm.c
21 ---------------
22 KSM maintains reverse mapping information for KSM pages in the stable
23 tree.
26 the node of the stable tree that represents such KSM page points to a
27 list of struct ksm_rmap_item and the ``page->mapping`` of the
[all …]
|
| /Documentation/filesystems/ |
| D | fsverity.rst | 1 .. SPDX-License-Identifier: GPL-2.0
6 fs-verity: read-only file-based authenticity protection
12 fs-verity (``fs/verity/``) is a support layer that filesystems can
14 of read-only files. Currently, it is supported by the ext4, f2fs, and
15 btrfs filesystems. Like fscrypt, not too much filesystem-specific
16 code is needed to support fs-verity.
18 fs-verity is similar to `dm-verity
19 <https://www.kernel.org/doc/Documentation/device-mapper/verity.txt>`_
21 filesystems supporting fs-verity, userspace can execute an ioctl that
22 causes the filesystem to build a Merkle tree for the file and persist
[all …]
|
| D | sharedsubtree.rst | 1 .. SPDX-License-Identifier: GPL-2.0
11 4) Use-case
19 -----------
27 It provides the necessary building blocks for features like per-user-namespace
31 -----------
49 mount --make-shared /mnt
51 Note: mount(8) command now supports the --make-shared flag,
57 # mount --bind /mnt /tmp
94 # mount --make-shared /mnt
97 # mount --bind /mnt /tmp
[all …]
|
| /Documentation/maintainer/ |
| D | rebasing-and-merging.rst | 1 .. SPDX-License-Identifier: GPL-2.0
8 Git source-code management system. Git is a powerful tool with a lot of
10 ways to use those features. This document looks in particular at the use
11 of rebasing and merging. Maintainers often get in trouble when they use
15 One thing to be aware of in general is that, unlike many other projects,
16 the kernel community is not scared by seeing merge commits in its
30 - Changing the parent (starting) commit upon which a series of patches is
33 release. We'll call this operation "reparenting" in the discussion
36 - Changing the history of a set of patches by fixing (or deleting) broken
38 the order in which commits are applied. In the following text, this
[all …]
|
| /Documentation/arch/sh/ |
| D | booting.rst | 1 .. SPDX-License-Identifier: GPL-2.0
4 ------------------
6 Device-tree compatible SH bootloaders are expected to provide the physical
7 address of the device tree blob in r4. Since legacy bootloaders did not
9 inter-operate with old bootloaders must either use a builtin DTB or
11 that does not use device tree. Support for the latter is being phased out
12 in favor of device tree.
|
| /Documentation/process/ |
| D | maintainer-kvm-x86.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 --------
17 -----
21 -----
22 KVM x86 is currently in a transition period from being part of the main KVM
23 tree, to being "just another KVM arch". As such, KVM x86 is split across the
24 main KVM tree, ``git.kernel.org/pub/scm/virt/kvm/kvm.git``, and a KVM x86
25 specific tree, ``github.com/kvm-x86/linux.git``.
28 main KVM tree, while all development for the next cycle is routed through the
29 KVM x86 tree. In the unlikely event that a fix for the current cycle is routed
[all …]
|
| D | 7.AdvancedTopics.rst | 12 -------------------------
14 The use of distributed version control for the kernel began in early 2002,
19 project. In current times, there are several free alternatives to
28 long document in its own right. Instead, the focus here will be on how git
29 fits into the kernel development process in particular. Developers who
32 https://git-scm.com/
34 https://www.kernel.org/pub/software/scm/git/docs/user-manual.html
40 available to others. A git-using developer should be able to obtain a copy
42 the tree, use branches, etc. An understanding of git's tools for the
45 remote branches, the index, fast-forward merges, pushes and pulls, detached
[all …]
|
| D | maintainer-tip.rst | 1 .. SPDX-License-Identifier: GPL-2.0
3 The tip tree handbook
6 What is the tip tree?
7 ---------------------
9 The tip tree is a collection of several subsystems and areas of
10 development. The tip tree is both a direct development tree and a
11 aggregation tree for several sub-maintainer trees. The tip tree gitweb URL
14 The tip tree contains the following subsystems:
16 - **x86 architecture**
18 The x86 architecture development takes place in the tip tree except
[all …]
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices | 3 is documented in Documentation/admin-guide/sysfs-rules.rst
7 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
9 Any device associated with a device-tree node will have
11 node in /sys/firmware/devicetree/
15 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
22 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
29 Contact: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
32 to the device (in <major>:<minor> format).
|
| /Documentation/devicetree/bindings/display/bridge/ |
| D | synopsys,dw-hdmi.yaml | 1 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
3 ---
4 $id: http://devicetree.org/schemas/display/bridge/synopsys,dw-hdmi.yaml#
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
10 - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
13 This document defines device tree properties for the Synopsys DesignWare HDMI
14 TX controller (DWC HDMI TX) IP core. It doesn't constitute a full device tree
15 binding specification by itself but is meant to be referenced by device tree
16 bindings for the platform-specific integrations of the DWC HDMI TX.
18 When referenced from platform device tree bindings the properties defined in
[all …]
|
| /Documentation/power/powercap/ |
| D | dtpm.rst | 1 .. SPDX-License-Identifier: GPL-2.0
9 as a whole in order to prevent the temperature to go above the
33 powercap entries in the sysfs directory and implement the backend
36 The DTPM is a tree representation describing the power constraints
39 The nodes of the tree are a virtual description aggregating the power
42 The leaves of the tree are the real power manageable devices.
48 `-- pkg
50 |-- pd0 (cpu0-3)
52 `-- pd1 (cpu4-5)
56 SoC (400mW - 3100mW)
[all …]
|
| /Documentation/dev-tools/ |
| D | checkuapi.rst | 1 .. SPDX-License-Identifier: GPL-2.0-only
7 The UAPI checker (``scripts/check-uapi.sh``) is a shell script which
8 checks UAPI header files for userspace backwards-compatibility across
9 the git tree.
14 This section will describe the options with which ``check-uapi.sh``
19 check-uapi.sh [-b BASE_REF] [-p PAST_REF] [-j N] [-l ERROR_LOG] [-i] [-q] [-v]
23 -b BASE_REF Base git reference to use for comparison. If unspecified or empty,
24 will use any dirty changes in tree to UAPI files. If there are no
26 -p PAST_REF Compare BASE_REF to PAST_REF (e.g. -p v6.1). If unspecified or empty,
29 -j JOBS Number of checks to run in parallel (default: number of CPU cores).
[all …]
|
12345678910>>...32