Once the information in a file has been read, removing
the file will signal to the underlying persistent storage
- device that it can reclaim the space for later re-use::
+ device that it can reclaim the space for later reuse::
$ rm /sys/fs/pstore/dmesg-erst-1
8) now the system is bootable and additional installation tasks can be
performed
-The key role of initrd here is to re-use the configuration data during
+The key role of initrd here is to reuse the configuration data during
normal system operation without requiring the use of a bloated "generic"
kernel or re-compiling or re-linking the kernel.
cat /sys/kernel/config/crash_dm_crypt_keys/count
2
- # To support CPU/memory hot-plugging, re-use keys already saved to reserved
+ # To support CPU/memory hot-plugging, reuse keys already saved to reserved
# memory
echo true > /sys/kernel/config/crash_dm_crypt_key/reuse
In the no-MMU case:
- - If one exists, the kernel will re-use an existing mapping to the
+ - If one exists, the kernel will reuse an existing mapping to the
same segment of the same file if that has compatible permissions,
even if this was created by another process.
then retrieve the value of the property by evaluating the KEY0 object.
However, using Name() this way has multiple problems: (1) ACPI limits
names ("KEY0") to four characters unlike DT; (2) there is no industry
-wide registry that maintains a list of names, minimizing re-use; (3)
+wide registry that maintains a list of names, minimizing reuse; (3)
there is also no registry for the definition of property values ("value0"),
-again making re-use difficult; and (4) how does one maintain backward
+again making reuse difficult; and (4) how does one maintain backward
compatibility as new hardware comes out? The _DSD method was created
to solve precisely these sorts of problems; Linux drivers should ALWAYS
use the _DSD method for device properties and nothing else.
- Can be 'online' or 'offline'.
Piping 'on' or 'off' sets the chpid logically online/offline.
Piping 'on' to an online chpid triggers path reprobing for all devices
- the chpid connects to. This can be used to force the kernel to re-use
+ the chpid connects to. This can be used to force the kernel to reuse
a channel path the user knows to be online, but the machine hasn't
created a machine check for.
When a task forks a child, its shadow stack PTEs are copied and both the
parent's and the child's shadow stack PTEs are cleared of the dirty bit.
Upon the next shadow stack access, the resulting shadow stack page fault
-is handled by page copy/re-use.
+is handled by page copy/reuse.
When a pthread child is created, the kernel allocates a new shadow stack
for the new thread. New shadow stack creation behaves like mmap() with respect
SATA etc.
The intention of creating this framework is to bring the PHY drivers spread
-all over the Linux kernel to drivers/phy to increase code re-use and for
+all over the Linux kernel to drivers/phy to increase code reuse and for
better code maintainability.
This framework will be of use only to devices that use external PHY (PHY
Line disciplines are registered with tty_register_ldisc() passing the ldisc
structure. At the point of registration the discipline must be ready to use and
it is possible it will get used before the call returns success. If the call
-returns an error then it won’t get called. Do not re-use ldisc numbers as they
+returns an error then it won’t get called. Do not reuse ldisc numbers as they
are part of the userspace ABI and writing over an existing ldisc will cause
demons to eat your computer. You must not re-register over the top of the line
discipline even with the same data or your computer again will be eaten by
``gadget`` framework. To do that, the system software relies on small
additions to those programming interfaces, and on a new internal
component (here called an "OTG Controller") affecting which driver stack
-connects to the OTG port. In each role, the system can re-use the
+connects to the OTG port. In each role, the system can reuse the
existing pool of hardware-neutral drivers, layered on top of the
controller driver interfaces (:c:type:`usb_bus` or :c:type:`usb_gadget`).
Such drivers need at most minor changes, and most of the calls added to
Misc
----
-Some applications may want to keep a channel around and re-use it
+Some applications may want to keep a channel around and reuse it
rather than open and close a new channel for each use. relay_reset()
can be used for this purpose - it resets a channel to its initial
state without reallocating channel buffer memory or destroying
"max_threshold_occupancy":
Read/write file provides the largest value (in
bytes) at which a previously used LLC_occupancy
- counter can be considered for re-use.
+ counter can be considered for reuse.
Finally, in the top level of the "info" directory there is a file
named "last_cmd_status". This is reset with every "command" issued
account in the first place and returning invalid property sets from _DSD must be
avoided. For this reason, it may not be possible to make _DSD return a property
set following the given DT binding literally and completely. Still, for the
-sake of code re-use, it may make sense to provide as much of the configuration
+sake of code reuse, it may make sense to provide as much of the configuration
data as possible in the form of device properties and complement that with an
ACPI-specific mechanism suitable for the use case at hand.
SoC/Chipset to appear only in ACPI namespace. These are typically devices
that are accessed through memory-mapped registers.
-In order to support this and re-use the existing drivers as much as
+In order to support this and reuse the existing drivers as much as
possible we decided to do following:
- Devices that have no bus connector resource are represented as
All new gamepads are supposed to comply with this mapping. Please report any
bugs, if they don't.
-There are a lot of less-featured/less-powerful devices out there, which re-use
+There are a lot of less-featured/less-powerful devices out there, which reuse
the buttons from this protocol. However, they try to do this in a compatible
fashion. For example, the "Nintendo Wii Nunchuk" provides two trigger buttons
and one analog stick. It reports them as if it were a gamepad with only one
the timing window between ``xyzzy()`` and calling
``fcntl(fd, F_SETFD, FD_CLOEXEC)``, where an unexpected ``fork()`` and
``execve()`` in another thread could leak a descriptor to
-the exec'ed program. (However, resist the temptation to re-use the actual value
+the exec'ed program. (However, resist the temptation to reuse the actual value
of the ``O_CLOEXEC`` constant, as it is architecture-specific and is part of a
numbering space of ``O_*`` flags that is fairly full.)
...
555 x32 xyzzy __x32_compat_sys_xyzzy
-If no pointers are involved, then it is preferable to re-use the 64-bit system
+If no pointers are involved, then it is preferable to reuse the 64-bit system
call for the x32 ABI (and consequently the entry in
arch/x86/entry/syscalls/syscall_64.tbl is unchanged).
configuration of that preset with the correct pin setup, etc.
Thus, if you have a newer machine with a slightly different PCI SSID
(or codec SSID) from the existing one, you may have a good chance to
-re-use the same model. You can pass the ``model`` option to specify the
+reuse the same model. You can pass the ``model`` option to specify the
preset model instead of PCI (and codec-) SSID look-up.
What ``model`` option values are available depends on the codec chip.
projects / thirdparty / kernel / linux.git / commitdiff
