| /linux/Documentation/process/ |
| H A D | 3.Early-stage.rst | 22 Consider an example: some years ago, developers working with Linux audio
30 To the audio developers, this security module was sufficient to solve their
40 resulting disagreement left those developers feeling disillusioned with the
44 There are a number of very good Linux kernel developers, but they
51 The reality of the situation was different; the kernel developers were far
91 - It's entirely possible that other developers have thought about the
109 core kernel developers' opinion, should have been implemented in the
122 avoided with some early discussion with the kernel developers.
128 When developers decide to take their plans public, the next question will
133 linux-kernel; you are more likely to reach developers with expertise in the
[all …]
|
| H A D | researcher-guidelines.rst | 35 on developers must be distinctly opt-in.
43 explicit agreement of, and full disclosure to, the individual developers
44 involved. Developers cannot be interacted with/experimented on without
55 one-way demand placed on busy developers with no corresponding benefit to
74 To help clarify: sending patches to developers *is* interacting
101 below) and follow up on any feedback from other developers.
104 contain at least the following details, so that developers have
164 resulting patches, and there by reduces the burden on other developers.
|
| H A D | contribution-maturity-model.rst | 18 strong talent pipeline, developers should be allowed and encouraged to
25 influence of individual developers, increase the collaboration of
32 the organization, including management and developers at all seniority
80 * The percentage of kernel developers who have made upstream
81 contributions relative to the total kernel developers in the
|
| H A D | 6.Followthrough.rst | 9 developers can make is to conclude that their work is now done. In truth,
26 developers as they review the code. Working with reviewers can be, for
27 many developers, the most intimidating part of the kernel development
48 agendas at the expense of your own. Kernel developers often expect to
128 patch. Now other developers working with that tree will get the patch by
139 developers and, possibly, moving some patches between trees to ensure that
152 may be a new round of comments from developers who had not been aware of
155 though; you still need to be responsive to developers who have questions or
186 development community remembers developers who lose interest in their code
|
| H A D | embargoed-hardware-issues.rst | 98 The hardware security team identifies the developers (domain experts) who
100 response team can bring in further developers (domain experts) to address
103 All involved developers pledge to adhere to the embargo rules and to keep
140 developers (domain experts) who should be informed initially about the
141 issue after confirming with the developers that they will adhere to this
142 Memorandum of Understanding and the documented process. These developers
148 While individual developers might be covered by a non-disclosure agreement
150 in their role as Linux kernel developers. They will, however, agree to
191 developers via a secure connection. The repository contains the main
268 involved developers and response teams as the patches need to be kept up to
|
| H A D | stable-api-nonsense.rst | 109 stopping to slow down. As such, the kernel developers find bugs in
133 provides the ability for new developers to accidentally use the old
137 In both of these instances, all developers agreed that these were
142 to extra work for the USB developers. Since all Linux USB developers do
185 - Other developers will add features to your driver.
|
| H A D | 8.Conclusion.rst | 23 Beyond that, a valuable resource for kernel developers is:
62 been helped by an impressively large group of developers, all of whom are
|
| H A D | handling-regressions.rst | 8 Linux kernel development" means in practice for developers. It complements
56 All the details on Linux kernel regressions relevant for developers
135 tools and scripts used by other kernel developers or Linux distributions; one of
252 * Developers, when trying to reach the time periods mentioned above, remember
257 * Reviewers, you are kindly asked to assist developers in reaching the time
267 More aspects regarding regressions developers should be aware of
276 developers or projects likely to be affected to evaluate or even test the
341 reporters and developers. In fact, only reporters are burdened with an extra
346 For developers there normally is no extra work involved, they just need to make
707 developers to understand. Reality matters. Your personal wishes matter
[all …]
|
| H A D | howto.rst | 143 developers, and help solve the issue.
213 source tree. Working with the developers in charge of this project, you
305 kernel subsystem developers --- expose their current state of
346 what kind of information is needed by the kernel developers to help track
356 improve your skills, and other developers will be aware of your presence.
357 Fixing bugs is one of the best ways to get merits among other developers,
373 developers participate on the Linux Kernel Mailing list. Details on how
417 Kernel developers don't want to deal with
|
| /linux/Documentation/ABI/testing/ |
| H A D | sysfs-devices-xenbus | 3 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
10 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
17 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
26 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
34 Contact: Xen Developers mailing list <xen-devel@lists.xenproject.org>
|
| H A D | sysfs-bus-pci | 72 Contact: Linux PCI developers <linux-pci@vger.kernel.org>
80 Contact: Linux PCI developers <linux-pci@vger.kernel.org>
105 Contact: Linux PCI developers <linux-pci@vger.kernel.org>
116 Contact: Linux PCI developers <linux-pci@vger.kernel.org>
123 Contact: Linux PCI developers <linux-pci@vger.kernel.org>
132 Contact: Linux PCI developers <linux-pci@vger.kernel.org>
446 Contact: Linux PCI developers <linux-pci@vger.kernel.org>
589 Contact: Linux PCI developers <linux-pci@vger.kernel.org>
|
| /linux/Documentation/admin-guide/ |
| H A D | reporting-regressions.rst | 13 for kernel developers are left to Documentation/process/handling-regressions.rst.
51 it happens by accident, developers that caused it are expected to quickly fix
63 Note the "practical use case" in the first sentence of this section: developers
144 Developers of the affected code area should try to locate the culprit on their
150 run additional tests afterwards to pinpoint the exact root cause. Developers
180 something might break. This is in the interest of the kernel developers to make
186 Additionally, the kernel developers want to make it simple and appealing for
198 Exceptions to this rule are extremely rare; in the past developers almost always
220 Developers should fix any reported regression as quickly as possible, to provide
222 running into the issue; nevertheless developers need to take enough time and
[all …]
|
| /linux/Documentation/doc-guide/ |
| H A D | contributing.rst | 7 Good documentation helps to bring new developers in and helps established
8 developers work more effectively. Without top-quality documentation, a lot
16 Kernel documentation improvements can be made by developers at a variety of
138 from the documentation build, then we can start expecting developers to
148 Developers are encouraged to write kerneldoc comments for their code, but
162 specifically aimed at developers working within the relevant subsystem.
208 the cooperation of developers familiar with the subsystem in question, of
209 course. Developers are often more than willing to cooperate with people
300 developers and users will thank you.
|
| /linux/Documentation/core-api/ |
| H A D | asm-annotations.rst | 16 Nevertheless, assemblers provide developers with such annotations to aid
17 debuggers throughout assembly. On top of that, developers also want to mark
23 developers have been using ``ENTRY``, ``END``, ``ENDPROC``, and other
93 this code needs hints like ``UNWIND_HINT_REGS`` provided by developers.
113 for special cases where developers do not want this implicit alignment.
124 So in most cases, developers should write something like in the following
206 ``SYM_END``, or ``SYM_ENTRY`` at last. Normally, developers should avoid using
|
| /linux/Documentation/ |
| H A D | index.rst | 35 Manuals for use by developers working to interface with the rest of the
49 Various other manuals with useful information for all kernel developers.
70 developers seeking information on the kernel's user-space APIs.
|
| /linux/Documentation/maintainer/ |
| H A D | rebasing-and-merging.rst | 45 There are a few rules of thumb that can help developers to avoid the worst
56 developers know not to base work on them. Developers will sometimes
172 resolution - often better than the developers involved.
220 should not prevent developers from doing the right thing when the need
|
| /linux/Documentation/bpf/libbpf/ |
| H A D | libbpf_overview.rst | 10 kernel hooks, allowing BPF application developers to focus only on BPF program
23 and tracing helpers, allowing developers to simplify BPF code writing.
24 * Supports BPF CO-RE mechanism, enabling BPF developers to write portable
121 system. The BPF helpers definition allows developers to use them in BPF code as
167 associated with BPF development and allows developers to write portable BPF
|
| /linux/Documentation/trace/rv/ |
| H A D | monitor_rtapp.rst | 25 The `rtapp` monitor detects these patterns. It aids developers to identify
88 Application developers may purposely choose to have their real-time application
90 problem. Application developers must analyze the warnings to make a proper
|
| /linux/Documentation/userspace-api/media/v4l/ |
| H A D | selection-api-configuration.rst | 33 target. It is recommended for the driver developers to put the top/left
118 the driver developers to put the top/left corner at position ``(0,0)``.
125 this document. Driver developers are encouraged to keep padded rectangle
|
| /linux/Documentation/arch/riscv/ |
| H A D | patch-acceptance.rst | 3 arch/riscv maintenance guidelines for developers
44 ECR. (Developers may, of course, maintain their own Linux kernel trees
|
| /linux/Documentation/crypto/ |
| H A D | intro.rst | 15 specification, hints to developers of ciphers are provided. Pointers to
31 well as for developers implementing ciphers. This API specification,
|
| /linux/Documentation/admin-guide/media/ |
| H A D | faq.rst | 34 Together with the Linux Kernel, the Digital TV developers support
64 transponders available on your area. So, LinuxTV developers
101 by one of the Kernel driver developers.
|
| /linux/Documentation/filesystems/ |
| H A D | inotify.rst | 38 spaces is thus sensible. The current design is what user-space developers
60 - User-space developers prefer the current API. The Beagle guys, for
|
| /linux/sound/pci/au88x0/ |
| H A D | au88x0.c | 8 * the developers of OpenVortex, Jeff Muizelaar and Kester Maddock, from
10 * Thanks to the ALSA developers, they helped a lot working out
13 * and the forum, where developers could communicate.
|
| /linux/drivers/media/test-drivers/vidtv/ |
| H A D | Kconfig | 7 validate the existing APIs in the media subsystem. It can also aid developers
|