| /linux/Documentation/rust/ |
| H A D | coding-guidelines.rst | 18 .. note:: Conventions on comments and documentation are not checked by
114 empty comment. Thus, at some point, the goal is to remove those comments.
117 Comments chapter
120 "Normal" comments (i.e. ``//``, rather than code documentation which starts
122 comments are, even though they will not be rendered. This improves consistency,
124 comments more easily. For instance:
131 Furthermore, just like documentation, comments are capitalized at the beginning
133 includes ``// SAFETY:``, ``// TODO:`` and other "tagged" comments, e.g.:
139 Comments should not be used for documentation purposes: comments are intended
142 sometimes it is useful to use both comments and documentation at the same time.
[all …]
|
| /linux/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/ |
| H A D | pwrseq.h | 43 /* comments here */ \
69 /* comments here */ \
86 /* comments here */ \
107 /* comments here */ \
121 /* comments here */ \
148 /* comments here */ \
168 /* comments here */ \
179 /* comments here */ \
187 /* comments here */ \
231 /* comments here */ \
[all …]
|
| /linux/Documentation/doc-guide/ |
| H A D | contributing.rst | 50 problems in kerneldoc comments in C code. While the documentation
66 comments that look like this::
86 [PATCH] PM / devfreq: Fix two malformed kerneldoc comments
88 Two kerneldoc comments in devfreq.c fail to adhere to the required format,
145 Languishing kerneldoc comments
148 Developers are encouraged to write kerneldoc comments for their code, but
149 many of those comments are never pulled into the docs build. That makes
152 the documentation to bring those comments in can help the community derive
156 overlooked comments.
160 kerneldoc comments for internal use; those should not be pulled into the
|
| /linux/drivers/net/wireless/realtek/rtlwifi/rtl8723be/ |
| H A D | pwrseq.h | 41 /* comments here */ \
112 /* comments here */ \
144 /* comments here */ \
171 /* comments here */ \
191 /* comments here */ \
218 /* comments here */ \
244 /* comments here */ \
262 /* comments here */ \
270 /* comments here */ \
314 /* comments here */ \
[all …]
|
| /linux/Documentation/process/ |
| H A D | 6.Followthrough.rst | 25 A patch of any significance will result in a number of comments from other
61 What all of this comes down to is that, when reviewers send you comments,
64 from happening. When you get review comments on a patch, take the time to
85 One fatal mistake is to ignore review comments in the hope that they will
87 responded to the comments you got the time before, you're likely to find
131 there's a good chance that you will get more comments from a new set of
132 reviewers; these comments need to be answered as in the previous round.
152 may be a new round of comments from developers who had not been aware of
|
| H A D | maintainer-kvm-x86.rst | 118 Except for a handful of special snowflakes, do not use kernel-doc comments for
123 Comments section in Development
125 Write comments using imperative mood and avoid pronouns. Use comments to
128 speak for itself. If the code itself is inscrutable, comments will not help.
138 not in comments. Instead, if necessary (see below), copy-paste the relevant
143 APM in comments. With few exceptions, KVM *must* honor architectural behavior,
253 modify comments. When possible and relevant, testing on both Intel and AMD is
|
| H A D | code-of-conduct.rst | 33 * Trolling, insulting/derogatory comments, and personal or political attacks
49 comments, commits, code, wiki edits, issues, and other contributions that are
|
| /linux/drivers/staging/rtl8723bs/include/ |
| H A D | hal_pwr_seq.h | 41 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
67 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
80 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
91 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
111 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
123 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
131 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
149 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
165 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
192 /* { offset, cut_msk, fab_msk|interface_msk, base|cmd, msk, value }, comments here*/ \
[all …]
|
| /linux/tools/net/sunrpc/xdrgen/ |
| H A D | xdrgen | 57 help="Add annotation comments",
82 help="Add annotation comments",
111 help="Add annotation comments",
|
| /linux/Documentation/devicetree/bindings/regulator/ |
| H A D | rohm,bd71815-regulator.yaml | 57 comments below for bucks/LDOs which support this. 0 means
77 comments below for bucks/LDOs which support this. 0 means
86 comments below for bucks/LDOs which support this. 0 means
|
| /linux/tools/lib/python/feat/ |
| H A D | parse_features.py | 116 comments = ""
171 comments += match.group(1)
213 "comments": comments,
320 com = self.data[feat]["comments"].strip()
322 self.emit("Comments")
|
| /linux/tools/docs/ |
| H A D | find-unused-docs.sh | 5 # This script detects files with kernel-doc comments for exported functions
35 echo "The following files contain kerneldoc comments for exported functions \
|
| /linux/scripts/coccinelle/misc/ |
| H A D | returnvar.cocci | 8 // Comments: Comments on code can be deleted if near code that is removed.
|
| /linux/Documentation/gpu/ |
| H A D | introduction.rst | 59 concepts. Documentation should be put into the code itself as kerneldoc comments
64 have formal kerneldoc comments. Use normal C comments if you feel like a comment
67 anything entirely private with ``/* private: */`` comments as per the
|
| /linux/scripts/ |
| H A D | kernel-doc | 94 documentation comments, and print formatted documentation
97 The documentation comments are identified by the ``/**``
119 Read C language source or header FILEs, extract embedded documentation comments,
122 The documentation comments are identified by the "/**" opening comment mark.
|
| H A D | kernel-doc.py | |
| /linux/rust/kernel/sync/atomic/ |
| H A D | internal.rs | 135 // TODO: Ideally we want to use the SAFETY comments written at the macro invocation
136 // (e.g. in `declare_and_impl_atomic_methods!()`, however, since SAFETY comments
137 // are just comments, and they are not passed to macros as tokens, therefore we
139 // attributes as an alternative for SAFETY comments, then we can use that for macro
|
| /linux/Documentation/bpf/libbpf/ |
| H A D | libbpf_naming_convention.rst | 148 The libbpf API is documented via comments above definitions in
149 header files. These comments can be rendered by doxygen and sphinx
151 convention in which these comments should be formatted.
|
| /linux/tools/lib/python/kdoc/ |
| H A D | parse_data_structs.py | 319 # Handle comments. They can be multilined
324 # Strip C99-style comments
335 # if lines end with \ or if they have multi-line comments
336 # With that, it can safely remove the entire comments,
344 # having comments stripped and multi-lines grouped.
|
| /linux/block/ |
| H A D | bfq-iosched.h | 102 /* head-of-line entity (see comments above) */
347 * queue it is deemed as soft real-time (see the comments on
389 * the comments on the choice of the queue for injection in
526 * weight-raised @bfq_queue (see the comments to the functions
541 * For a detailed explanation see comments on the computation
738 * a burst of activations, see the comments on the function
760 * details in the comments on the function bfq_handle_burst).
813 * Depth limits used in bfq_limit_depth (see comments on the
873 * see comments to bfq_handle_burst.
986 * (see the comments to the function
[all …]
|
| H A D | bfq-iosched.c | 59 * detail in the comments on the function
207 * Time limit for merging (see comments in bfq_setup_cooperator). Set
272 * for interactive queues automatically (see the comments at the
280 * applications on the reference device (see the comments on
362 * described at the beginning of these comments.
780 * comments on the likely() at the beginning of
801 * bfqq cannot be merged any longer (see comments in in bfq_pos_tree_add_move()
831 * temporarily empty (for more details, see the comments in the
972 * See the comments to the function bfq_weights_tree_add() for considerations
1208 /* Empty burst list and add just bfqq (see comments on bfq_handle_burst) */
[all …]
|
| /linux/arch/powerpc/tools/ |
| H A D | head_check.sh | 62 echo "ERROR: see comments in arch/powerpc/tools/head_check.sh" 1>&2
76 echo "ERROR: see comments in arch/powerpc/tools/head_check.sh" 1>&2
|
| /linux/rust/syn/ |
| H A D | attr.rs | 36 /// - Outer one-line doc comments like `/// Example`.
38 /// - Inner one-line doc comments like `//! Please file an issue`.
63 /// All doc comments are represented in the NameValue style with a path of
138 /// # Doc comments
140 /// The compiler transforms doc comments, such as `/// comment` and `/*!
149 /// /// Single line doc comments
152 /// * Multi-line comments...
161 /// #[doc = r" Single line doc comments"]
164 /// * Multi-line comments...
|
| /linux/drivers/net/ethernet/brocade/bna/ |
| H A D | bfa_defs_status.h | 16 * NOTE: The error msgs are auto generated from the comments. Only singe line
17 * comments are supported
|
| /linux/tools/memory-model/Documentation/ |
| H A D | litmus-tests.txt | 99 when running the test. Yes, you can add your own comments to litmus
101 For now, you can use C-language comments in the C code, and these comments
371 spin loops, handling trivial linked lists, adding comments to litmus tests,
760 Comments
766 C-language comments (either "/* */" or "//"), while the other portions
767 use Ocaml comments "(* *)".
806 In short, use C-language comments in the C code and Ocaml comments in
809 On the other hand, if you prefer C-style comments everywhere, the
|