| /linux/Documentation/filesystems/ |
| H A D | vfs.rst | 18 to userspace programs. It also provides an abstraction within the
19 kernel which allows different filesystem implementations to coexist.
30 calls. The pathname argument that is passed to them is used by the VFS
31 to search through the directory entry cache (also known as the dentry
32 cache or dcache). This provides a very fast look-up mechanism to
34 in RAM and are never saved to disc: they exist only for performance.
36 The dentry cache is meant to be a view into your entire filespace. As
38 bits of the cache are missing. In order to resolve your pathname into a
39 dentry, the VFS may have to resort to creating dentries along the way,
46 An individual dentry usually has a pointer to an inode. Inodes are
[all …]
|
| H A D | path-lookup.rst | 12 It has subsequently been updated to reflect changes in the kernel
18 Introduction to pathname lookup
22 exploration is needed to discover, is that it is complex. There are
24 combine to confuse the unwary reader. Computer science has long been
25 acquainted with such complexity and has tools to help manage it. One
28 them until the final part. Well before we get to symlinks we have
29 another major division based on the VFS's approach to locking which
30 will allow us to review "REF-walk" and "RCU-walk" separately. But we
32 distinctions we need to clarify first.
39 Pathnames (sometimes "file names"), used to identify objects in the
[all …]
|
| /linux/Documentation/firmware-guide/acpi/ |
| H A D | osi.rst | 8 to find out what the operating system supports. Eg. If BIOS
10 can evaluate that method, look to see if it supports 'XYZ'
11 and answer YES or NO to the BIOS.
19 How to use _OSI
23 to be compatible with Linux, and those that were never tested with Linux,
24 but where Linux was installed to replace the original OS (Windows or OSX).
26 The larger group is the systems tested to run only Windows. Not only that,
27 but many were tested to run with just one specific version of Windows.
28 So even though the BIOS may use _OSI to query what version of Windows is running,
31 exposes Linux to an entire category of BIOS bugs.
[all …]
|
| /linux/Documentation/admin-guide/mm/ |
| H A D | transhuge.rst | 16 But in the future it can expand to other filesystems.
32 factor will affect all subsequent accesses to the memory for the whole
46 going to run faster.
49 ability to allocate memory in blocks that are bigger than a base page
52 memory (for example 16K, 32K, 64K, etc). These THPs continue to be
53 PTE-mapped, but in many cases can still provide similar benefits to
57 variant and there is less memory to clear in each page fault. Some
58 architectures also employ TLB compression mechanisms to squeeze more
63 THP can be enabled system wide or restricted to certain tasks or even
72 if compared to the reservation approach of hugetlbfs by allowing all
[all …]
|
| H A D | userfaultfd.rst | 9 and more generally they allow userland to take control of various
20 region(s) result in a message being delivered to the userfaultfd, notifying
26 1) ``read/POLLIN`` protocol to notify a userland thread of the faults
30 registered in the ``userfaultfd`` that allows userland to efficiently
31 resolve the userfaults it receives via 1) or to manage the virtual
34 The real advantage of userfaults if compared to regular virtual memory
43 passed using unix domain sockets to a manager process, so the same
46 (well of course unless they later try to use the ``userfaultfd``
56 There are two ways to create a new userfaultfd, each of which provide ways to
57 restrict access to this functionality (since historically userfaultfds which
[all …]
|
| /linux/Documentation/process/ |
| H A D | 3.Early-stage.rst | 7 to jump right in and start coding. As with any significant project,
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
20 with the proposed solution, and that can lead to difficulties.
23 sought a way to run applications without dropouts or other artifacts caused
25 kernel module intended to hook into the Linux Security Module (LSM)
26 framework; this module could be configured to give specific applications
27 access to the realtime scheduler. This module was implemented and sent to
30 To the audio developers, this security module was sufficient to solve their
31 immediate problem. To the wider kernel community, though, it was seen as a
[all …]
|
| H A D | backporting.rst | 17 Some developers may never really have to deal with backporting patches,
18 merging branches, or resolving conflicts in their day-to-day work, so
21 techniques you can use to make the process smoother and increase your
24 This document aims to be a comprehensive, step-by-step guide to
27 Applying the patch to a tree
33 often does for the Linux kernel, you will need to apply it to a tree
37 quite picky about the patch applying perfectly to your source tree. In
38 fact, you've probably had nightmares about ``.rej`` files and trying to
39 edit the patch to make it apply.
41 It is strongly recommended to instead find an appropriate base version
[all …]
|
| H A D | submitting-patches.rst | 3 Submitting patches: the essential guide to getting your code into the kernel
6 For a person or company who wishes to submit a change to the Linux
15 for a list of items to check before submitting code.
19 This documentation assumes that you're using ``git`` to prepare your patches.
20 If you're unfamiliar with ``git``, you would be well-advised to learn how to
32 ``git`` to obtain one. You'll want to start with the mainline repository,
37 Note, however, that you may not want to develop against the mainline tree
38 directly. Most subsystem maintainers run their own trees and want to see
40 in the MAINTAINERS file to find that tree, or simply ask the maintainer if
50 motivated you to do this work. Convince the reviewer that there is a
[all …]
|
| H A D | applying-patches.rst | 3 Applying Patches To The Linux Kernel
12 manually, you'll almost certainly want to look at using Git instead.
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
16 one of the many trees/branches should be applied to. Hopefully this document
17 will explain this to you.
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
31 To correctly apply a patch you need to know what base it was generated from
33 should both be present in the patch file metadata or be possible to deduce
[all …]
|
| /linux/Documentation/core-api/ |
| H A D | kobject.rst | 2 Everything you never wanted to know about kobjects, ksets, and ktypes
14 all of which make reference to each other. In an attempt to make things
16 adding detail as we go. To that end, here are some quick definitions of
21 objects to be arranged into hierarchies), a specific type, and,
29 If it does, the reference counting for the object is sure to be messed
34 what happens to the kobject when it is created and destroyed.
37 or belong to different ktypes. The kset is the basic container type for
43 of those directories corresponds to a kobject in the same kset.
45 We'll look at how to create and manipulate all of these types. A bottom-up
46 approach will be taken, so we'll go back to kobjects.
[all …]
|
| H A D | xarray.rst | 14 resizable array. Unlike a hash, it allows you to sensibly go to the
15 next or previous entry in a cache-efficient manner. In contrast to a
16 resizable array, there is no need to copy data or change MMU mappings in
17 order to grow the array. It is more memory-efficient, parallelisable
19 RCU to perform lookups without locking.
31 nor for function pointers. You can store pointers to statically allocated
37 a value entry by calling xa_is_value(), and convert it back to
40 Some users want to tag the pointers they store in the XArray. You can
41 call xa_tag_pointer() to create an entry with a tag, xa_untag_pointer()
42 to turn a tagged entry back into an untagged pointer and xa_pointer_tag()
[all …]
|
| /linux/Documentation/admin-guide/pm/ |
| H A D | intel_pstate.rst | 20 may not be supported. [To understand ``intel_pstate`` it is necessary to know
21 how ``CPUFreq`` works in general, so this is the time to read
29 refer to Intel Software Developer’s Manual [2]_). However, the ``CPUFreq`` core
32 ``intel_pstate`` maps its internal representation of P-states to frequencies too
34 practical for ``intel_pstate`` to supply the ``CPUFreq`` core with a table of
35 available frequencies due to the possible size of it, so the driver does not do
41 object corresponds to one logical CPU and ``CPUFreq`` policies are effectively
42 equivalent to CPUs. In particular, this means that they become "inactive" every
43 time the corresponding CPU is taken offline and need to be re-initialized when
47 only way to pass early-configuration-time parameters to it is via the kernel
[all …]
|
| /linux/drivers/staging/most/Documentation/ |
| H A D | driver_usage.txt | 8 MOST defines the protocol, hardware and software layers necessary to allow
12 also supports various speed grades up to 150 Mbps.
16 Cars continue to evolve into sophisticated consumer electronics platforms,
17 increasing the demand for reliable and simple solutions to support audio,
18 video and data communications. MOST can be used to connect multiple
19 consumer devices via optical or electrical physical layers directly to one
22 audio/video streaming. Therefore, the driver perfectly fits to the mission
23 of Automotive Grade Linux to create open source software solutions for
26 The MOST driver uses module stacking to divide the associated modules into
36 arbitrarily combined with the core to meet the connectivity of the desired
[all …]
|
| /linux/Documentation/bpf/ |
| H A D | prog_cgroup_sysctl.rst | 10 The hook has to be attached to a cgroup and will be called every time a
11 process inside that cgroup tries to read from or write to sysctl knob in proc.
16 ``BPF_CGROUP_SYSCTL`` attach type has to be used to attach
17 ``BPF_PROG_TYPE_CGROUP_SYSCTL`` program to a cgroup.
22 ``BPF_PROG_TYPE_CGROUP_SYSCTL`` provides access to the following context from
34 or written. This field is read-write. Writing to the field sets the starting
36 will be writing to. Writing zero to the field can be used e.g. to override
39 value to the field can be used to access part of sysctl value starting from
41 0``, e.g. writes to numeric sysctl entries must always be at file position
52 * ``0`` means "reject access to sysctl";
[all …]
|
| /linux/drivers/bluetooth/ |
| H A D | Kconfig | 32 This driver is required if you want to use Bluetooth devices with
35 Say Y here to compile support for Bluetooth USB devices into the
36 kernel or say M to compile it as module (btusb).
42 Say Y here to enable USB autosuspend for Bluetooth USB devices by
56 Say Y here to enable USB poll_sync for Bluetooth USB devices by
68 Say Y here to compile support for Broadcom protocol.
80 Say Y here to compile support for MediaTek protocol.
91 Say Y here to compile support for Realtek protocol.
98 This driver is required if you want to use Bluetooth device with
101 Say Y here to compile support for Bluetooth SDIO devices into the
[all …]
|
| /linux/Documentation/trace/ |
| H A D | user_events.rst | 9 User based trace events allow user processes to create events and trace data
11 To enable this feature, build your kernel with CONFIG_USER_EVENTS=y.
17 Programs can also use /sys/kernel/tracing/dynamic_events to register and
18 delete user based events via the u: prefix. The format of the command to
20 requires CAP_PERFMON due to the event persisting, otherwise -EPERM is returned.
22 Typically programs will register a set of events that they wish to expose to
24 process tells the kernel which address and bit to reflect if any tool has
37 Registering within a user process is done via ioctl() out to the
38 /sys/kernel/tracing/user_events_data file. The command to issue is
47 /* Input: Bit in enable address to use */
[all …]
|
| /linux/drivers/clocksource/ |
| H A D | renesas-ostm.c | 46 static void ostm_timer_stop(struct timer_of *to) in ostm_timer_stop() argument
48 if (readb(timer_of_base(to) + OSTM_TE) & TE) { in ostm_timer_stop()
49 writeb(TT, timer_of_base(to) + OSTM_TT); in ostm_timer_stop()
52 * Read back the register simply to confirm the write operation in ostm_timer_stop()
56 while (readb(timer_of_base(to) + OSTM_TE) & TE) in ostm_timer_stop()
61 static int __init ostm_init_clksrc(struct timer_of *to) in ostm_init_clksrc() argument
63 ostm_timer_stop(to); in ostm_init_clksrc()
65 writel(0, timer_of_base(to) + OSTM_CMP); in ostm_init_clksrc()
66 writeb(CTL_FREERUN, timer_of_base(to) + OSTM_CTL); in ostm_init_clksrc()
67 writeb(TS, timer_of_base(to) + OSTM_TS); in ostm_init_clksrc()
[all …]
|
| /linux/drivers/gpu/drm/i915/ |
| H A D | Kconfig.profile | 8 Beware setting this value lower, or close to heartbeat interval
9 rounded to whole seconds times three, in order to avoid allowing
13 May be 0 to disable the timeout.
19 When listening to a foreign fence, we install a supplementary timer
20 to ensure that we are always signaled and our userspace is able to
24 May be 0 to disable the timeout, and rely on the foreign fence being
31 On runtime suspend, as we suspend the device, we have to revoke
32 userspace GGTT mmaps and force userspace to take a pagefault on
38 May be 0 to disable the extra delay and solely use the device level
45 The driver sends a periodic heartbeat down all active engines to
[all …]
|
| /linux/Documentation/admin-guide/sysctl/ |
| H A D | vm.rst | 18 The files in this directory can be used to tune the operation
20 the writeout of dirty data to disk.
90 admin_reserve_kbytes defaults to min(3% of free pages, 8MB)
92 That should provide enough for the admin to log in and kill a process,
95 Systems running under overcommit 'never' should increase this to account
96 for the full Virtual Memory Size of programs used to recover. Otherwise,
97 root may not be able to log in to recover the system.
116 Available only when CONFIG_COMPACTION is set. When 1 is written to the file,
126 background. Write of a non zero value to this tunable will immediately
127 trigger the proactive compaction. Setting it to 0 disables proactive compaction.
[all …]
|
| /linux/Documentation/driver-api/ |
| H A D | uio-howto.rst | 21 All that is really needed is some way to handle an interrupt and provide
22 access to the memory space of the device. The logic of controlling the
23 device does not necessarily have to be within the kernel, as the device
24 does not need to take advantage of any of other resources that the
28 To address this situation, the userspace I/O system (UIO) was designed.
40 controlled completely by writing to this memory.
49 I'd like to thank Thomas Gleixner and Benedikt Spranger of Linutronix,
57 would love to hear from you. Please email me at hjk@hansjkoch.de.
64 - only one small kernel module to write and maintain.
67 tools and libraries you're used to.
[all …]
|
| /linux/Documentation/networking/ |
| H A D | af_xdp.rst | 18 redirect ingress frames to other XDP enabled netdevs, using the
20 XDP programs to redirect frames to a memory buffer in a user-space
28 to have at least one of these rings for each socket. An RX or TX
29 descriptor ring points to a data buffer in a memory area called a
31 to be copied between RX and TX. Moreover, if a packet needs to be kept
32 for a while due to a possible retransmit, the descriptor that points
33 to that packet can be changed to point to another and reused right
43 FILL ring is used by the application to send down addr for the kernel
44 to fill in with RX packet data. References to these frames will then
53 The socket is then finally bound with a bind() call to a device and a
[all …]
|
| /linux/Documentation/driver-api/usb/ |
| H A D | writing_usb_driver.rst | 13 types of devices in the 2.2.7 kernel (mice and keyboards), to over 20
17 vendor-specific devices (such as USB to serial converters, digital
22 almost all vendor-specific devices. Each vendor decides to implement a
23 custom protocol to talk to their device, so a custom driver usually
24 needs to be created. Some vendors are open with their USB protocols and
26 them, and developers are forced to reverse-engineer. See Resources for
27 some links to handy reverse-engineering tools.
29 Because each different protocol causes a new driver to be created, I
35 different pieces and what needs to be done to customize it to your
41 If you are going to write a Linux USB driver, please become familiar
[all …]
|
| /linux/Documentation/doc-guide/ |
| H A D | contributing.rst | 3 How to help improve kernel documentation
7 Good documentation helps to bring new developers in and helps established
13 it needs to be to support a project of this size and importance.
15 This guide is for contributors who would like to improve that situation.
17 skill levels; they are a relatively easy way to learn the kernel process in
19 documentation maintainer's list of tasks that most urgently need to be
25 There is an endless list of tasks that need to be carried out to get our
26 documentation to where it should be. This list contains a number of
27 important items, but is far from exhaustive; if you see a different way to
38 straightforward, but it must be approached in the right way to be
[all …]
|
| /linux/Documentation/power/ |
| H A D | pci.rst | 7 An overview of concepts and the Linux kernel's interfaces related to PCI power
11 This document only covers the aspects of power management specific to PCI
12 devices. For general description of the kernel's interfaces related to device
13 power management refer to Documentation/driver-api/pm/devices.rst and
30 In general, power management is a feature allowing one to save energy by putting
35 completely inactive. However, when it is necessary to use the device once
36 again, it has to be put back into the "fully functional" state (full-power
37 state). This may happen when there are some data for the device to handle or
38 as a result of an external event requiring the device to be active, which may
44 approach, that is referred to as the native PCI power management (native PCI PM)
[all …]
|
| /linux/include/linux/ |
| H A D | highmem.h | 18 * @page: Pointer to the page to be mapped
28 * The returned virtual address is globally visible and valid up to the
29 * point where it is unmapped via kunmap(). The pointer can be handed to
41 * @page: Pointer to the page which was mapped by kmap()
43 * Counterpart to kmap(). A NOOP for CONFIG_HIGHMEM=n and for mappings of
50 * @addr: The address to look up
52 * Returns: The page which is mapped to @addr.
57 * kmap_flush_unused - Flush all unused kmap mappings in order to
64 * @page: Pointer to the page to be mapped
71 * management is stack based. The unmap has to be in the reverse order of
[all …]
|