Searched full:they (Results 1 – 25 of 1154) sorted by relevance
12345678910>>...47
| /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
55 you need to pay attention to the technical observations that they are
78 One fatal mistake is to ignore review comments in the hope that they will
79 go away. They will not go away. If you repost code without having
89 time; if you help them get a running start, they will be in a better mood
90 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 | 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
212 on the assumption that they will be able to avoid serious integration
|
| 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
127 Some kernels are designated "long term" kernels; they will receive support
171 developers on that list reply with any comments they may have. This
187 make those changes or justify why they should not be made. If your
230 of the kernel they manage; they are the ones who will (usually) accept a
241 the patches they have selected for merging from their repositories. If
284 mailing list, or they may apply to a part of the kernel for which there is
305 lists when they are assembled; they can be downloaded from:
[all …]
|
| /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
|
| /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/driver-api/usb/ |
| D | dma.rst | 12 though they still must provide DMA-ready buffers (see
13 ``Documentation/DMA-API-HOWTO.txt``). 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
112 - Some drivers may prefer to work with the model that they're mapping large
131 They cannot be used for setup_packet buffers in control requests.
134 they don't have current users. See the source code. Other than the dmasync
|
| D | anchors.rst | 10 to know they've all completed or to call usb_kill_urb
45 are called in the reverse temporal order they were submitted.
53 are processed in the reverse temporal order they were submitted.
56 the call returns. They may be unlinked later but will be unlinked in
|
| /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
70 developers feel they are finished. They cannot be removed from the
73 It's up to the developer to place their interfaces in the category they
|
| /Documentation/driver-api/ |
| D | device_connection.rst | 19 They are only descriptions which are not tied to either of the devices directly.
22 defined in firmware (not yet supported) or they can be built-in.
37 endpoint device, or they can request the description itself.
|
| 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/devicetree/bindings/sram/ |
| D | milbeaut-smp-sram.txt | 4 Once they get powered up in the bootloader, they stay at the specific part
|
| /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/livepatch/ |
| D | livepatch.rst | 55 they need to be aware of each other and not step over each other's toes.
66 Functions are there for a reason. They take some input parameters, get or
71 example, they add a NULL pointer or a boundary check, fix a race by adding
128 3. For idle "swapper" tasks, since they don't ever exit the kernel, they
138 especially applies to kthreads. They may not be woken up and would need
213 a) patching user tasks when they cross the kernel/user space
243 sources. A good practice is to add a prefix to the names so that they
245 they can be declared as static because they are not called directly
248 The patch contains only functions that are really modified. But they
285 only when they are available.
[all …]
|
| /Documentation/hid/ |
| D | hid-transport.rst | 61 They allocate HID device objects and register them with HID core. Transport
72 device failures. Once transport drivers detect unplug or failure events, they
85 driver in whatever way they like. They might just be the same as asynchronous
86 channels, but they can also provide acknowledgement reports, automatic
96 will describe them as two bi-directional channels as they have several
122 - OUTPUT Report: Output reports change device states. They are sent from host
238 Called from HID device drivers once they want to use the device. Transport
247 Called from HID device drivers once they are done with a device. Transport
252 Transport drivers are free to ignore it and deinitialize devices after they
259 Called from HID device drivers once they are interested in data reports.
[all …]
|
| /Documentation/admin-guide/ |
| D | reporting-bugs.rst | 63 MAINTAINERS file. They can help coordinate bugfix and disclosure. See
104 information they're really interested in. If some information is not
161 they may not be able to address your bug in a day, a week, or two weeks.
162 If they don't answer your email, they may be on vacation, or at a Linux
169 kernel, and they may not work on the weekends. Maintainers are scattered
170 around the world, and they may not work in your time zone. Unless you
|
| /Documentation/ABI/stable/ |
| D | sysfs-module | 20 what they accomplish.
23 considered stable, only the fact that they will be
|
| /Documentation/devicetree/bindings/usb/ |
| D | gr-udc.txt | 21 - epobufsizes : Array of buffer sizes for OUT endpoints when they differ
27 - epibufsizes : Array of buffer sizes for IN endpoints when they differ
|
| /Documentation/virt/ |
| D | paravirt_ops.rst | 28 Usually these operations correspond to low level critical instructions. They
34 because they include sensitive instructions or some of code paths in
|
| /Documentation/devicetree/bindings/firmware/ |
| D | intel,ixp4xx-network-processing-engine.yaml | 18 consecutive memory locations. They are all included in the same
19 device node since they are not independent of each other.
|
12345678910>>...47