| /OK3568_Linux_fs/buildroot/docs/manual/ |
| H A D | developers.txt | 5 == DEVELOPERS file and get-developers
8 lists the developers involved with various areas of Buildroot. Thanks
9 to this file, the +get-developers+ tool allows to:
11 - Calculate the list of developers to whom patches should be sent, by
13 relevant developers. See xref:submitting-patches[] for details.
15 - Find which developers are taking care of a given architecture or
20 We ask developers adding new packages, new boards, or generally new
29 The +get-developers+ tool, located in +utils/+ allows to use
33 +get-developers+ will return the appropriate +git send-email+
37 - When using the +-a <arch>+ command line option, +get-developers+ will
[all …]
|
| H A D | manual.txt | 10 The Buildroot manual is written by the Buildroot developers.
15 Copyright (C) 2004-2020 The Buildroot developers
69 include::developers.txt[]
|
| H A D | resources.txt | 16 main method of interaction for Buildroot users and developers.
38 better as it will reach more people, both developers and users.
68 for all Buildroot developers.
|
| H A D | eclipse-integration.txt | 6 While a part of the embedded Linux developers like classical text
8 of other embedded Linux developers like richer graphical interfaces to
|
| /OK3568_Linux_fs/kernel/drivers/gpu/drm/i915/ |
| H A D | Kconfig.debug | 15 Recommended for driver developers only.
43 Recommended for driver developers only.
56 Recommended for driver developers only.
68 Recommended for driver developers only.
80 Recommended for driver developers only.
94 Recommended for driver developers only.
108 Recommended for driver developers only.
121 Recommended for driver developers only.
133 Recommended for driver developers only.
145 Recommended for driver developers only.
[all …]
|
| H A D | Kconfig.unstable | 15 number of interested parties (userspace driver developers) can
19 Recommended for driver developers _only_.
|
| /OK3568_Linux_fs/kernel/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 | 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
173 developers on that list reply with any comments they may have. This
211 One of the largest mistakes made by kernel developers (or their employers)
224 unassisted. The way the kernel developers have addressed this growth is
337 where, with luck, they will come to the attention of other developers and
[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
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
164 the most experienced developers can be improved, though. Perhaps the best
[all …]
|
| H A D | 1.Intro.rst | 10 and the kinds of frustrations that developers and their employers can
28 have been encountered by other developers are discussed. Some requirements for
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
139 - While kernel developers strive to maintain a stable interface to user
155 developers. Surprising results can come from empowering your user
[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
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
283 developers and users) in a deployed system; lockdep allows them to be found
337 of new code into the kernel, make life easier for other developers, and
[all …]
|
| 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
225 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
121 patch. Now other developers working with that tree will get the patch by
132 developers and, possibly, moving some patches between trees to ensure that
145 may be a new round of comments from developers who had not been aware of
148 though; you still need to be responsive to developers who have questions or
179 development community remembers developers who lose interest in their code
|
| H A D | 8.Conclusion.rst | 11 are also something which all kernel developers should
25 Beyond that, a valuable resource for kernel developers is:
64 been helped by an impressively large group of developers, all of whom are
|
| /OK3568_Linux_fs/buildroot/utils/ |
| H A D | getdeveloperlib.py | 230 developers = []
260 developers.append(Developer(name, files))
270 developers.append(Developer(name, files))
271 return developers
274 def check_developers(developers, basepath=None): argument
284 for d in developers:
|
| /OK3568_Linux_fs/buildroot/package/bitwise/ |
| H A D | Config.in | 9 kernel developers and device drivers developers.
|
| /OK3568_Linux_fs/buildroot/support/scripts/ |
| H A D | pkg-stats | 50 self.developers = None
52 def set_developers(self, developers): argument
56 self.developers = [
58 for developer in developers
274 def set_developers(self, developers): argument
278 self.developers = [
280 for dev in developers
284 if self.developers:
285 self.status['developers'] = ("ok", "{} developers".format(len(self.developers)))
1131 developers = parse_developers()
[all …]
|
| /OK3568_Linux_fs/yocto/meta-openembedded/meta-oe/recipes-extended/bitwise/ |
| H A D | bitwise_0.43.bb | 5 kernel developers and device drivers developers."
|
| /OK3568_Linux_fs/kernel/Documentation/ |
| 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
92 this code needs hints like ``UNWIND_HINT_REGS`` provided by developers.
112 for special cases where developers do not want this implicit alignment.
123 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
|
| /OK3568_Linux_fs/buildroot/package/mksh/ |
| H A D | Config.in | 8 pdksh developers or contributors. mksh is not affiliated
16 portable product; one with developers that listen to
|
| /OK3568_Linux_fs/kernel/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
|
| /OK3568_Linux_fs/app/forlinx/quectelCM/libmnl/ |
| H A D | README | 3 libmnl is a minimalistic user-space library oriented to Netlink developers.
12 * Easy to use: the library simplifies the work for Netlink-wise developers.
|
| /OK3568_Linux_fs/yocto/meta-openembedded/meta-perl/recipes-perl/libconfig/ |
| H A D | libconfig-autoconf-perl_0.319.bb | 6 developers as GNU Autoconf <http://www.gnu.org/software/autoconf/> does for \
7 Shell developers."
|
| /OK3568_Linux_fs/yocto/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…
|
| /OK3568_Linux_fs/yocto/poky/meta/classes/ |
| H A D | extrausers.bbclass | 8 # groupadd developers; \
11 # groupmod -g 1020 developers; \
|