Lines Matching refs:be
18 …ent cannot cover every situation, so the following general guidelines should be used as a fallback:
20 * The code style should be consistent within each individual file.
21 * In the case of creating new files, the style should be consistent within each file in a given dir…
24 Line length is recommended to be not more than 80 characters, including comments.
25 [Tab stop size should be assumed to be 8-characters wide].
38 These comments should be used in normal cases.
39 To document a public API, a doxygen-like format must be used: refer to :ref:`doxygen_guidelines`.
64 After any copyright header, a blank line should be left before any other contents, e.g. include sta…
72 In DPDK sources, the include files should be ordered as following:
98 Headers should be protected against multiple inclusion with the usual:
120 If the macro encapsulates a compound statement, enclose it in a do-while loop, so that it can be us…
121 Any final statement-terminating semicolon should be supplied by the macro invocation rather than th…
134 …Wherever possible, enums and inline functions should be preferred to macros, since they provide ad…
141 Conditional compilation should be used only when absolutely necessary,
142 as it increases the number of target binaries that need to be built and tested.
144 to allow ifdefs/macros to be replaced by C conditional in some cases.
151 should be used instead of conditional compilation.
154 then conditional compilation should be used, as described in this section.
158 In most cases, these environment-specific files should be created inside the EAL library,
163 * When code is conditionally compiled using ``#ifdef`` or ``#if``, a comment may be added following…
165 …omment should be used only for (subjectively) long regions, regions greater than 20 lines, or wher…
166 …may be made for cases where code is conditionally not compiled for the purposes of lint(1), or oth…
167 * The comment should be separated from the ``#endif`` or ``#else`` by a single space.
168 * For short conditionally compiled regions, a closing comment should not be used.
197 While this can be done using the conditional compilation directives,
199 this can also be done in many cases using regular ``if`` statements
249 * Enum types should be used in preference to macros #defining a set of (sequential) values.
250 * Enum types should be prefixed with ``rte_`` and the elements by a suitable prefix [generally star…
296 * For existing structures, additions to structures should be added to the end so for backward compa…
299 …following extremely long types, which therefore cannot be easily aligned with the rest, should be …
311 * Major structures should be declared at the top of the file in which they are used, or in separate…
312 * Use of the structures should be by separate variable declarations and those declarations must be …
328 Thus, the previous example would be better written:
344 This should be used in all data-path code, when there are several consumer and/or producers to avoi…
398 In addition, they must be declared exactly once, whereas an incomplete structure type can be mentio…
400 The header that defines the typedef must be included before the header that uses it, or by the head…
401 or there must be a back-door mechanism for obtaining the typedef.
405 As stated when discussing macros, typedefs should be preferred to macros in cases like this.
442 * For control statements (if, while, etc.), continuation it is recommended that the next line be in…
499 * Parts of a for loop may be left empty.
509 * Braces that are not necessary should be left out.
541 However, remember that other people may be more easily confused than you.
546 Exits should be 0 on success, or 1 on failure.
559 * Variables should be declared at the start of a block of code rather than in the middle.
560 …The exception to this is when the variable is ``const`` in which case the declaration must be at t…
563 …initializing variables in the declarations, only the last variable on a line should be initialized.
564 If multiple variables are to be initialized when defined, put one per line.
591 * Functions local to one source module should be declared static, and should not be prototyped unle…
592 * Functions used from other parts of code (external API) must be prototyped in the relevant include…
593 * Function prototypes should be listed in a logical order, preferably alphabetical unless there is …
596 * Functions that are part of an external API should be documented using Doxygen-like comments above…
606 * Short function prototypes should be contained on a single line.
607 Longer prototypes, e.g. those with many parameters, can be split across multiple lines.
608 …The second and subsequent lines should be further indented as for line statement continuations as …
625 * The function type should be on a line by itself preceding the function.
626 * The opening brace of the function body should be on a line by itself.
637 …Hiding file declarations in what appears to be a local scope is undesirable and will elicit compla…
638 * Old-style (K&R) function declaration should not be used, use ANSI function declarations instead a…
639 * Long argument lists should be wrapped as described above in the function prototypes section.
682 The error type should be indicated by setting the variable ``rte_errno`` appropriately.
686 * Where already standard in a given library, the alternative error approach may be used where the n…
688 * For functions where no error is possible, the function type should be ``void`` not ``int``.
697 * Values in return statements should not be enclosed in parentheses.
735 …ler builtin and allow the developer to indicate if the branch is likely to be taken or not. Exampl…
745 The use of ``likely()`` and ``unlikely()`` should only be done in performance critical paths,
747 These macros should be avoided in non-performance-critical code.
752 * All functions and variables that are local to a file must be declared as ``static`` because it ca…
753 * Functions that should be inlined should to be declared as ``static inline`` and can be defined in…
756 …Static functions defined in a header file must be declared as ``static inline`` in order to preven…
761 The ``const`` attribute should be used as often as possible when a variable is read-only.
766 The ``asm`` and ``volatile`` keywords do not have underscores. The AT&T syntax should be used.
767 Input and output operands should be named to avoid confusion, as shown in the following example:
802 logging of a particular topic, the ``--log-level`` parameter can be provided
828 logging output by using "specializations". A specialization could be the
831 An example could be the initialization log messages getting one
851 All Python code should be compliant with
854 The ``pep8`` tool can be used for testing compliance with the guidelines.
866 but the mode can be manually enabled/disabled using the
870 and should be added to the component lists in the ``meson.build`` files in the
877 The ``meson.build`` file for a new DPDK library should be of the following basic
890 For a library ``meson.build`` file, there are number of variables which can be
895 This variable should list out the files to be compiled up to create the
896 library. Files must be specified using the meson ``files()`` function.
905 also be set to explain to the user why the component is not being built.
906 A simple example of use would be:
918 Used to specify any additional cflags that need to be passed to compile
924 be assigned to using ``+=`` rather than overwriting using ``=``. The
925 dependencies should be specified as strings, each one giving the name of
930 variable may be omitted from the ``meson.build`` file. For example:
939 Used to specify external dependencies of this library. They should be
942 these, they should be checked to ensure the dependencies have been
943 found, and, if not, the ``build`` variable should be set to ``false``.
958 Used to return the list of header files for the library that should be
960 source files, these should be specified using the meson ``files()``
966 applications, these checks can be skipped by using the ``indirect_headers``
977 Used to indicate any additional header file paths which should be
982 it does not need to be specified here.
987 name, the name should be specified using this variable. In practice,
990 never be needed for new libraries.
996 library names differ, the ``version.map`` file should be named
1001 This variable can be used to pass to the library build some pre-built
1007 This variable should be used when a library is not to be built i.e. when
1008 ``build`` is set to "false", to specify the reason why a library will not be
1009 built. For missing dependencies this should be of the form
1015 has, this value should be set to ensure that the C files are compiled
1040 variable to allow the headers from that base directory to be found when
1041 compiling driver sources. Should be appended to using ``+=`` rather than
1042 overwritten using ``=``. The values appended should be meson include
1060 libraries that may need to be linked into the build - especially when
1061 using static libraries. Anything added here will be appended to the end
1082 * Indentation should be using 4 spaces, no hard tabs.
1084 * Line continuations should be doubly-indented to ensure visible difference from normal indentation.
1085 …Any line continuations beyond the first may be singly indented to avoid large amounts of indentati…
1088 brackets should be used in preference to escaping the line break.
1097 * Lists of files or components must be alphabetical unless doing so would cause errors.
1101 …* For a small number of list entries, generally 3 or fewer, all elements may be put on a single li…
1102 …In this case, the opening and closing braces of the list must be on the same line as the list item…
1105 it is recommended that the lists be put in the files with a *single* entry per line.
1106 In this case, the opening brace, or ``files`` function call must be on a line on its own,
1107 and the closing brace must similarly be on a line on its own at the end.
1108 To help with readability of nested sublists, the closing brace should be dedented to appear