| /openbmc/linux/drivers/gpu/drm/i915/ |
| H A D | Kconfig.debug | 15 Recommended for driver developers only.
22 depends on EXPERT # only for developers
48 Recommended for driver developers only.
61 Recommended for driver developers only.
73 Recommended for driver developers only.
88 Recommended for driver developers only.
100 Recommended for driver developers only.
114 Recommended for driver developers only.
128 Recommended for driver developers only.
141 Recommended for driver developers only.
[all …]
|
| /openbmc/linux/Documentation/process/ |
| H A D | 2.Process.rst | 7 with relatively small numbers of users and developers involved. With a
8 user base in the millions and with some 2,000 developers involved over the
16 The kernel developers use a loosely time-based release process, with a new
59 allowed, but such occasions are rare; developers who try to merge new
89 How do the developers decide when to close the development cycle and create
97 The developers' goal is to fix all known regressions before the stable
166 developers on that list reply with any comments they may have. This
204 One of the largest mistakes made by kernel developers (or their employers)
217 unassisted. The way the kernel developers have addressed this growth is
262 Developers will be interested in what other changes are pending to see
[all …]
|
| 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 | 1.Intro.rst | 10 and the kinds of frustrations that developers and their employers can
20 discussion of tools and mailing lists. Developers wanting to get started
28 have been encountered by other developers are discussed. Some requirements for
41 avoid problems at this important stage. Developers are cautioned against
61 With the growth of Linux has come an increase in the number of developers
73 these developers; anybody with the requisite skills can improve Linux and
78 involve over 1000 developers working for more than 100 different companies
91 intimidating to new developers, but there are good reasons and solid
101 community is always in need of developers who will help to make the kernel
120 Some companies and developers occasionally wonder why they should bother
[all …]
|
| H A D | 7.AdvancedTopics.rst | 8 number of topics which can be helpful for developers wanting to become a
26 still being civilized by its developers. This document will not attempt to
29 fits into the kernel development process in particular. Developers who
57 developers can get an account on kernel.org, but those are not easy to come
83 that, developers cannot easily collaborate if they do not have a shared
84 view of the project history; if you rewrite history which other developers
86 for those developers. So a simple rule of thumb applies here: history
117 radar. Kernel developers tend to get unhappy when they see that kind of
146 format the request as other developers expect, and will also check to be
154 topics" on the grounds that even beginning kernel developers should be
[all …]
|
| H A D | 4.Coding.rst | 8 code. It is the code which will be examined by other developers and merged
13 number of ways in which kernel developers can go wrong. Then the focus
29 leads to two independent hazards for kernel developers.
34 the standard; many developers will request that the code be reformatted
36 requires some uniformity of code to make it possible for developers to
47 urgently in need of coding style fixes. Developers may start to generate
88 programmer's early expectation. Kernel developers will routinely submit
183 locking after the fact is a rather more difficult task. Kernel developers
230 kernel. To that end, the kernel developers have put together an impressive
281 developers and users) in a deployed system; lockdep allows them to be found
[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 | 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
138 developers (domain experts) who should be informed initially about the
139 issue after confirming with the developers that they will adhere to this
140 Memorandum of Understanding and the documented process. These developers
146 While individual developers might be covered by a non-disclosure agreement
148 in their role as Linux kernel developers. They will, however, agree to
189 developers via a secure connection. The repository contains the main
230 the involved developers and response teams as the patches need to be kept
|
| 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 | 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 | maintainer-pgp-guide.rst | 9 This document is aimed at Linux kernel developers, and especially at
22 communication channels between developers via PGP-signed email exchange.
30 developers who create official kernel releases. These signatures offer a
32 kernel.org or any other mirrors are identical to what these developers
40 Trusting the developers, not infrastructure
47 that trust must always be placed with developers and never with the code
52 want to make sure that by placing trust into developers we do not simply
54 The goal is to provide a set of guidelines developers can use to create
212 The more signatures you have on your PGP key from other developers, the
426 …r a free Nitrokey Start`: https://www.kernel.org/nitrokey-digital-tokens-for-kernel-developers.html
[all …]
|
| /openbmc/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>
|
| /openbmc/docs/designs/ |
| H A D | ci-authorization.md | 26 openbmc/general-developers GitHub team. If the contributor is a member of the
27 team (or a general-developers sub-team), the automated CI processes are
29 the general-developers team, manual intervention (ok-to-test) is required by a
39 openbmc/general-developers GitHub team, the contributor must first be a member
44 openbmc/general-developers group membership administrative capability.
55 The proposal is to simply migrate the current openbmc/general-developers GitHub
|
| /openbmc/linux/Documentation/admin-guide/ |
| H A D | reporting-issues.rst | 22 issue. Check the :ref:`MAINTAINERS <maintainers>` file for how its developers
55 developers. It might be all that's needed for people already familiar with
98 needs to get reported to the kernel developers separately, unless they are
106 Find out how and where its developers expect reports. Note: most of the
174 switch from 5.9.15 to 5.10.5 does not qualify). The developers want to fix such
178 * Check if the kernel developers still maintain the Linux kernel version
247 * The Linux kernel developers are well aware this process is complicated and
254 request fixes from developers in the upstream Linux kernel community: such
272 issues to the Linux kernel developers.
284 Like most programmers, Linux kernel developers don't like to spend time dealing
[all …]
|
| 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 …]
|
| /openbmc/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
|
| /openbmc/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
144 Developers are encouraged to write kerneldoc comments for their code, but
158 specifically aimed at developers working within the relevant subsystem.
204 the cooperation of developers familiar with the subsystem in question, of
205 course. Developers are often more than willing to cooperate with people
296 developers and users will thank you.
|
| /openbmc/linux/Documentation/ABI/ |
| H A D | README | 30 these interfaces, so that the kernel developers can easily
53 the "testing" stage, so that kernel developers can work
54 with userspace developers to ensure that things do not
78 developers feel they are finished. They cannot be removed from the
|
| /openbmc/linux/Documentation/filesystems/ |
| H A D | xfs-maintainer-entry-profile.rst | 39 Developers can often be found in the IRC channel mentioned by the ``C:``
49 Senior developers tend to be more active participants in the IRC channel.
64 coverage goals of the project, negotiating with developers to decide
65 on new tests for new features, and making sure that developers and
134 developers write a design document to answer the following questions:
186 developers that have Reviewed-by tags for XFS changes to take a look and
|
| /openbmc/openbmc/poky/meta/files/common-licenses/ |
| H A D | NRL | 5 …ibution from the US Naval Research Laboratory (NRL) are copyrighted by their respective developers.
7 …nt is binding on those portions of the software. In all cases, the NRL developers have retained th…
9 …tware and documentation were developed at NRL by various people. Those developers have each copyri…
|
| /openbmc/linux/fs/btrfs/ |
| H A D | Kconfig | 79 developers.
98 any of the assertions trip. This is meant for btrfs developers only.
108 is meant to be used by btrfs developers for tracking down extent
|
| /openbmc/qemu/docs/system/devices/ |
| H A D | canokey.rst | 33 * libcanokey-qemu supports debugging output thus developers can
39 Then for developers:
41 * For developers on software with secure key support (e.g. FIDO2, OpenPGP),
43 * For secure key developers, USB packets between guest OS and CanoKey
|
| /openbmc/openbmc/meta-openembedded/meta-oe/recipes-support/libfido2/ |
| H A D | libfido2_1.15.0.bb | 5 HOMEPAGE = "https://developers.yubico.com/libfido2"
12 SRC_URI = "https://developers.yubico.com/${BPN}/Releases/${BPN}-${PV}.tar.gz"
|
| /openbmc/docs/tof/ |
| H A D | membership-and-voting.md | 45 | Jan 30th | July 30th | Developers disputing membership eligibility must submit a petition …
68 contributions to the project. By contributing to the project, developers gain a
87 cycle, normal developers are given a vote weight of 1 and highly-productive
88 developers are given a vote weight of 3.
|