Searched full:they (Results 1 – 25 of 1453) sorted by relevance
12345678910>>...59
| /Documentation/process/ |
| D | management-style.rst | 45 manage had better know the details better than you, so if they come to
51 Namely that you are in the wrong job, and that **they** should be managing
113 not. After all, if **they** aren't certain whether it's a good idea, you
114 sure as hell shouldn't encourage them by promising them that what they
115 work on will be included. Make them at least think twice before they
118 Remember: they'd better know more about the details than you do, and
119 they usually already think they have the answer to everything. The best
121 healthy dose of critical thinking on what they do.
125 clear which approach is better, they'll eventually figure it out. The
127 situation that they just give up.
[all …]
|
| D | 6.Followthrough.rst | 26 developers as they review the code. Working with reviewers can be, for
42 they see the same mistakes being made over and over again. If you get a
49 be working on the kernel years from now, but they understand that their
50 employer could change. They truly are, almost without exception,
51 working toward the creation of the best kernel they can; they are not
62 you need to pay attention to the technical observations that they are
85 One fatal mistake is to ignore review comments in the hope that they will
86 go away. They will not go away. If you repost code without having
96 time; if you help them get a running start, they will be in a better mood
97 when they revisit your code.
[all …]
|
| D | volatile-considered-harmful.rst | 8 changed outside of the current thread of execution; as a result, they are
10 being used. In other words, they have been known to treat volatile types
11 as a sort of easy atomic variable, which they are not. The use of volatile in
23 unwanted optimization. If they are being used properly, there will be no
38 primitives act as memory barriers - they are explicitly written to do so -
101 volatile should take a step back and think about what they are truly trying
105 they come with a justification which shows that the concurrency issues have
|
| D | stable-api-nonsense.rst | 42 the world, they neither see this interface, nor do they care about it at
50 the technical issues here (not to make light of the legal issues, they
54 kernel source interfaces. They both depend on each other, but we will
110 current interfaces, or figure out a better way to do things. If they do
111 that, they then fix the current interfaces to work better. When they do
138 important changes that needed to be made, and they were made, with
159 well as they can be (unused interfaces are pretty much impossible to
|
| D | 2.Process.rst | 45 merge window do not come out of thin air; they have been collected, tested,
63 exception is made for drivers for previously-unsupported hardware; if they
64 touch no in-tree code, they cannot cause regressions and should be safe to
128 Some kernels are designated "long term" kernels; they will receive support
166 developers on that list reply with any comments they may have. This
182 make those changes or justify why they should not be made. If your
225 of the kernel they manage; they are the ones who will (usually) accept a
236 the patches they have selected for merging from their repositories. If
279 mailing list, or they may apply to a part of the kernel for which there is
300 lists when they are assembled; they can be downloaded from:
[all …]
|
| D | 3.Early-stage.rst | 24 by excessive latency in the system. The solution they arrived at was a
33 onto processes which they would not otherwise have) and a risk to system
39 they had implemented; they were unwilling to accept alternatives. The
44 There are a number of very good Linux kernel developers, but they
47 time. They are much too "intelligent" to listen to lesser mortals.
53 the right solution to the problem than they were with a specific module.
92 problem; they may have ideas for a better solution, and may be willing
213 on the assumption that they will be able to avoid serious integration
|
| /Documentation/core-api/ |
| D | errseq.rst | 39 can tell whether the value has changed since they last checked it.
54 They're all handing him work to do -- so much he can't keep track of who
56 just want to know when he's finished all of the work they've handed him so
57 far and whether he made any mistakes since they last asked.
59 He might have made the mistake on work they didn't actually hand him,
75 The supervisors come in and get an initial read for the day. They
88 Now they start handing him tasks to do. Every few minutes they ask him to
89 finish up all of the work they've handed him so far. Then they ask him
106 and they each get the error when they next check. Subsequent calls will
111 whether one was made since they last checked, and the latest value
|
| D | asm-annotations.rst | 31 When these macros are used correctly, they help assemblers generate a nice
96 ``.text``. Data do not contain instructions, so they have to be treated
97 specially by the tools: they should not treat the bytes as instructions,
110 most frequent markings**. They are used for functions with standard calling
111 conventions -- global and local. Like in C, they both align the functions to
162 ``SYM_{CODE,FUNC}_START`` and ``SYM_{CODE,FUNC}_END``. They are very similar
163 to C labels, except they can be made global. An example of use::
200 In the end, they expand to ``SYM_DATA_START`` with ``SYM_DATA_END``
211 symbol marked by them. They are used either in ``_LABEL`` variants of the
|
| /Documentation/locking/ |
| D | spinlocks.rst | 39 using spinlocks they tend to expand to areas you might not have noticed
41 shared data structures **everywhere** they are used. The spinlocks are most
47 touches a shared variable has to agree about the spinlock they want
57 (rw_lock) versions of the spinlocks are sometimes useful. They allow multiple
100 The single spin-lock primitives above are by no means the only ones. They
102 but partly **because** they are safe they are also fairly slow. They are slower
103 than they'd need to be, because they do have to disable interrupts
|
| /Documentation/admin-guide/pm/ |
| D | strategies.rst | 32 ``inactive`` (idle). If they are active, they have to be in power states
33 allowing them to process data and to be accessed by software. In turn, if they
34 are inactive, ideally, they should be in low-power states in which they may not
47 sleep states than when they are runtime idle most of the time.
|
| /Documentation/input/ |
| D | gamepad.rst | 56 all devices have both or any, but they are present at most times.
80 bugs, if they don't.
83 the buttons from this protocol. However, they try to do this in a compatible
111 If only 2 action-buttons are present, they are reported as BTN_SOUTH and
117 If only 3 action-buttons are present, they are reported as (from left
119 If the buttons are aligned perfectly vertically, they are reported as
124 If all 4 action-buttons are present, they can be aligned in two
125 different formations. If diamond-shaped, they are reported as BTN_NORTH,
152 If analog-sticks provide digital buttons, they are mapped accordingly as
167 If only one trigger-button combination is present (upper+lower), they are
|
| /Documentation/arch/riscv/ |
| D | uabi.rst | 25 extension category. If multiple 'Z' extensions are named, they will be
31 extensions are listed, they will be ordered alphabetically.
35 extensions are listed, they will be ordered alphabetically.
38 extensions. If multiple non-standard extensions are listed, they will be
68 Misaligned scalar accesses are supported in userspace, but they may perform
|
| /Documentation/filesystems/bcachefs/ |
| D | CodingStyle.rst | 32 are logically impossible. (Or, make them debug mode assertions if they're
76 Pretty printers are wonderful, because they compose and you can use them
78 make your error messages much easier to write (therefore they will actually
79 exist) and much more informative. And they can be used from sysfs/debugfs, as
90 Tracepoints shouldn't be the first thing you reach for. They're an important
97 The humble counter is an incredibly useful tool. They're cheap and simple to
112 a user waiting. They'll thank you in the long run, and when they understand
113 what you're doing you'll be amazed at how patient they're happy to be. Users
114 like to help - otherwise they wouldn't be reporting the bug in the first place.
141 existing code. Sometimes these can be the best projects, because they can lead
|
| /Documentation/driver-api/acpi/ |
| D | scan_handlers.rst | 19 acpi_device objects are referred to as "device nodes" in what follows, but they
29 appropriate data, but some of them require additional handling after they have
38 basis of the device node's hardware ID (HID). They are performed by objects
73 scope (if they have scan handlers). Next, it unregisters all of the device
79 is the order in which they are matched against device nodes during namespace
83 first time and they cannot be removed from it.
|
| /Documentation/ABI/ |
| D | README | 26 programs can start to rely on these interfaces, but they must be
57 sure they are working in a proper way and do not need to
78 developers feel they are finished. They cannot be removed from the
81 It's up to the developer to place their interfaces in the category they
|
| /Documentation/devicetree/bindings/memory-controllers/ |
| D | mc-peripheral-props.yaml | 11 They could be common properties like reg or they could be controller
13 to be defined in the peripheral node because they are per-peripheral
|
| /Documentation/userspace-api/gpio/ |
| D | gpio-v2-lineinfo-changed-read.rst | 50 The kernel timestamps events when they occur and stores them in a buffer
51 from where they can be read by userspace at its convenience using `read()`.
55 The buffer may overflow if bursts of events occur quicker than they are read
59 Events read from the buffer are always in the same order that they were
|
| D | gpio-lineinfo-changed-read.rst | 54 The kernel timestamps events when they occur and stores them in a buffer
55 from where they can be read by userspace at its convenience using `read()`.
59 The buffer may overflow if bursts of events occur quicker than they are read
63 Events read from the buffer are always in the same order that they were
|
| /Documentation/networking/devlink/ |
| D | devlink-trap.rst | 145 - Traps incoming packets that the device decided to drop in case they are
153 - Traps packets that the device decided to drop in case they need to be
159 forwarding the only port from which they should be transmitted through
160 is the port from which they were received
163 - Traps packets that the device decided to drop in case they hit a
171 - Traps packets that the device decided to drop because they could not be
175 - Traps packets that the device decided to drop because they need to
179 - Traps packets that the device decided to drop because they need to be
180 routed and they have a unicast destination IP and a multicast destination
184 - Traps packets that the device decided to drop because they need to be
[all …]
|
| /Documentation/dev-tools/kunit/ |
| D | style.rst | 8 strongly encouraged that they are named and written according to the guidelines
10 they may break some tooling, may conflict with other tests, and may not be run
23 To make tests easy to find, they are grouped into suites and subsystems. A test
42 If a test subsystem name has multiple components, they should be separated by
71 The KUnit API and tools do not explicitly know about subsystems. They are
84 Test suites are named after the subsystem they are part of. If a subsystem
89 subsystem (for example, both unit tests and integration tests), they should be
128 Tests should be named after what they are testing. This is often the name of the
130 As tests are C functions, they should be named and written in accordance with
|
| /Documentation/usb/ |
| D | ehci.rst | 16 can be used on USB 1.1 systems, but they slow down to USB 1.1 speeds.
19 into an EHCI controller, they are given to a USB 1.1 "companion"
21 such devices. When USB 1.1 devices plug into USB 2.0 hubs, they
137 Device drivers shouldn't care whether they're running over EHCI or not,
138 but they may want to check for "usb_device->speed == USB_SPEED_HIGH".
147 badly when they see different faults than OHCI or UHCI report.
217 In the Linux 2.5 kernels, new usb_sg_*() api calls have been defined; they
218 queue all the buffers from a scatterlist. They also use scatterlist DMA
220 help make high speed transfers run as fast as they can.
|
| /Documentation/driver-api/tty/ |
| D | tty_ldisc.rst | 21 returns an error then it won’t get called. Do not re-use ldisc numbers as they
71 While these functions are slightly slower than the old code they should have
72 minimal impact as most receive logic uses the flip buffers and they only
73 need to take a reference when they push bits up through the driver.
|
| /Documentation/driver-api/usb/ |
| D | dma.rst | 12 though they still must provide DMA-ready buffers (see
13 Documentation/core-api/dma-api-howto.rst). That's how they've worked through
14 the 2.4 (and earlier) kernels, or they can now be DMA-aware.
45 memory. They work like kmalloc and kfree versions that give you the right
55 Most drivers should **NOT** be using these primitives; they don't need
|
| /Documentation/driver-api/ |
| D | s390-drivers.rst | 26 not strictly considered I/O devices. They are considered here as well,
27 although they are not the focus of this document.
35 The css bus contains the subchannels available on the system. They fall
38 * Standard I/O subchannels, for use by the system. They have a child
53 so-called channel attached devices. They are addressed via I/O
|
| /Documentation/livepatch/ |
| D | livepatch.rst | 42 they need to be aware of each other and not step over each other's toes.
53 Functions are there for a reason. They take some input parameters, acquire or
58 example, they add a NULL pointer or a boundary check, fix a race by adding
115 3. For idle "swapper" tasks, since they don't ever exit the kernel, they
125 especially applies to kthreads. They may not be woken up and would need
200 a) patching user tasks when they cross the kernel/user space
230 sources. A good practice is to add a prefix to the names so that they
232 they can be declared as static because they are not called directly
235 The patch contains only functions that are really modified. But they
272 only when they are available.
[all …]
|
12345678910>>...59