Searched full:much (Results 1 – 25 of 2613) sorted by relevance
12345678910>>...105
| /linux-6.12.1/drivers/media/pci/bt8xx/ |
| D | bttv-audio-hook.c | 60 /* Not much to do here */ in gvbctv3pci_audio()
162 /* Not much to do here */ in avermedia_tvphone_audio()
193 /* Not much to do here */ in avermedia_tv_stereo_audio()
231 /* Not much to do here */ in lt9415_audio()
264 /* Not much to do here */ in terratv_audio()
336 /* Not much to do here */ in pvbt878p9b_audio()
377 /* Not much to do here */ in fv2000s_audio()
413 /* Not much to do here */ in windvr_audio()
450 /* Not much to do here */ in adtvk503_audio()
|
| /linux-6.12.1/Documentation/filesystems/bcachefs/ |
| D | errorcodes.rst | 10 This gives us much better error messages and makes debugging much easier. Any
29 where the error was generated; good names for error codes mean much more
|
| D | CodingStyle.rst | 56 invariants with runtime checks - much like the way people working in
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
135 Nobody writes all perfect code that all gets shipped, and you'll be much more
150 much less risk of wasted effort if the feature you were going for doesn't work
|
| /linux-6.12.1/Documentation/arch/x86/ |
| D | orc-unwinder.rst | 12 format of the ORC data is much simpler than DWARF, which in turn allows
13 the ORC unwinder to be much simpler and faster.
63 ORC debuginfo's advantage over DWARF itself is that it's much simpler.
66 much simpler, meaning fewer bugs, which is especially important for
69 The simpler debuginfo format also enables the unwinder to be much faster
114 annotations are needed than what DWARF would need, so they're much more
|
| /linux-6.12.1/include/linux/ |
| D | timex.h | 90 * SHIFT_PLL is used as a dampening factor to define how much we
93 * much of the current value in time_offset we correct for each
100 * However this seems to increase convergence time much too long.
114 * SHIFT_FLL is used as a dampening factor to define how much we
|
| D | stringhash.h | 18 * malicious inputs; much slower hash functions are required for that.
62 * this computes a different hash function much faster.
|
| D | nfs_iostat.h | 48 * traffic. NORMAL + DIRECT shows how much data is going through
50 * without much NORMAL or DIRECT traffic shows that applications
|
| /linux-6.12.1/arch/arm64/kernel/ |
| D | watchdog_hld.c | 10 * Arm CPUs in the market which are clocked much less than 5 GHz. On the other
11 * hand, we can't make it much higher as it would lead to a large hard-lockup
|
| /linux-6.12.1/Documentation/process/ |
| D | botching-up-ioctls.rst | 14 actually only used once interfaces. But the clear downside is that there's much
110 paths pretty much for free for graphics drivers. Also, be consistent with
160 an asynchronous event on a pollable file descriptor. It fits much better
208 it's much quicker to push a driver-private interface than engaging in
214 * Consider other interfaces than ioctls. A sysfs attribute is much better for
|
| /linux-6.12.1/arch/mips/include/asm/ |
| D | floppy.h | 42 * driver otherwise. It doesn't matter much for performance anyway, as most
47 * Actually this needs to be a bit more complicated since the so much different
|
| /linux-6.12.1/Documentation/scheduler/ |
| D | sched-nice-design.rst | 9 pestered us to make nice +19 tasks use up much less CPU time.
17 much stronger than they were before in 2.4 (and people were happy about
39 So that if someone wanted to really renice tasks, +19 would give a much
|
| D | sched-design-CFS.rst | 69 side of the tree as much as possible.
115 The CFS scheduler has a much stronger handling of nice levels and SCHED_BATCH
116 than the previous vanilla scheduler: both types of workloads are isolated much
157 without the core code assuming too much about them.
|
| /linux-6.12.1/Documentation/ |
| D | subsystem-apis.rst | 8 from the point of view of a kernel developer. Much of the information here
66 **Fixme**: much more organizational work is needed here.
|
| /linux-6.12.1/Documentation/arch/powerpc/ |
| D | kasan.txt | 48 this at run-time based on how much physical memory we have, but this requires
54 requires knowing how much contiguous physical memory a system has _at compile
|
| /linux-6.12.1/lib/zstd/common/ |
| D | error_private.c | 29 … case PREFIX(frameParameter_windowTooLarge): return "Frame requires too much memory for decoding"; in ERR_getErrorString()
38 case PREFIX(tableLog_tooLarge): return "tableLog requires too much memory : unsupported"; in ERR_getErrorString()
|
| /linux-6.12.1/net/batman-adv/ |
| D | bitarray.c | 60 /* sequence number is much newer, probably missed a lot of packets */ in batadv_bit_get_packet()
72 /* received a much older packet. The other host either restarted in batadv_bit_get_packet()
|
| /linux-6.12.1/include/uapi/linux/ |
| D | resource.h | 76 * The first two don't need much. The latter will take as
77 * much as it can get. 8MB is a reasonably sane default.
|
| /linux-6.12.1/fs/reiserfs/ |
| D | README | 107 Mikhail Gilula was a brilliant innovator that has shown much generosity.
125 Igor Zagorovsky is writing much of the new item handler and extent code
149 than the ones just named. SuSE has helped in much more than just
|
| /linux-6.12.1/Documentation/driver-api/driver-model/ |
| D | devres.rst | 15 5. Overhead : How much do we have to pay for this?
35 For one reason or another, low level drivers don't receive as much
38 Init failure path is worse because it's much less travelled while
102 driver can have much simpler init and exit code. Init path basically
|
| /linux-6.12.1/drivers/tty/ |
| D | ehv_bytechan.c | 358 /* Find out how much data needs to be read, and then ask the TTY layer in ehv_bc_tty_rx_isr()
359 * if it can handle that much. We want to ensure that every byte we in ehv_bc_tty_rx_isr()
407 * This function, which can be called in interrupt context, dequeues as much
463 * the data first in a circular buffer, and then dequeue as much of that data
468 * layer how much data it can safely send to us. We guarantee that
470 * too much data.
538 * how much write room the driver can guarantee will be sent OR BUFFERED. This
601 * If we could ask the hypervisor how much data is still in the TX buffer, or
|
| /linux-6.12.1/arch/arm/include/asm/ |
| D | kgdb.h | 34 * make our lives much much simpler. :)
|
| /linux-6.12.1/Documentation/misc-devices/ |
| D | apds990x.rst | 26 might vary quite much depending the spectrum of the light source.
68 to saturate much before that. Real max value varies depending
|
| /linux-6.12.1/Documentation/admin-guide/pm/ |
| D | strategies.rst | 42 then it takes much less time and effort to start executing user space code than
45 typically the system can spend much more time in a sleep state than it can be
|
| /linux-6.12.1/fs/jffs2/ |
| D | compr_rtime.c | 69 /* Tell the caller how much we managed to compress, and how much space it took */ in jffs2_rtime_compress()
|
| /linux-6.12.1/drivers/block/drbd/ |
| D | drbd_vli.h | 20 * the bitmap transfer time can take much too long,
37 * integers would be much worse than plaintext.
48 * We don't care too much about "excellent" compression ratio for large
50 * or 1000 is not that much of an issue.
51 * We do not want to waste too much on short runlengths in the "noisy"
|
12345678910>>...105