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].
30 …However, it is expected that the recommendations should be followed in all but the rarest situatio…
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…
139 * When code is conditionally compiled using ``#ifdef`` or ``#if``, a comment may be added following…
141 …omment should be used only for (subjectively) long regions, regions greater than 20 lines, or wher…
142 …may be made for cases where code is conditionally not compiled for the purposes of lint(1), or oth…
143 * The comment should be separated from the ``#endif`` or ``#else`` by a single space.
144 * For short conditionally compiled regions, a closing comment should not be used.
170 …tional compilation should be used only when absolutely necessary, as it increases the number of ta…
189 * Enum types should be used in preference to macros #defining a set of (sequential) values.
190 * Enum types should be prefixed with ``rte_`` and the elements by a suitable prefix [generally star…
236 * For existing structures, additions to structures should be added to the end so for backward compa…
239 …following extremely long types, which therefore cannot be easily aligned with the rest, should be …
251 * Major structures should be declared at the top of the file in which they are used, or in separate…
252 * Use of the structures should be by separate variable declarations and those declarations must be …
268 Thus, the previous example would be better written:
284 This should be used in all data-path code, when there are several consumer and/or producers to avoi…
338 In addition, they must be declared exactly once, whereas an incomplete structure type can be mentio…
340 The header that defines the typedef must be included before the header that uses it, or by the head…
341 or there must be a back-door mechanism for obtaining the typedef.
345 As stated when discussing macros, typedefs should be preferred to macros in cases like this.
382 * For control statements (if, while, etc.), continuation it is recommended that the next line be in…
439 * Parts of a for loop may be left empty.
449 * Braces that are not necessary should be left out.
481 However, remember that other people may be more easily confused than you.
486 Exits should be 0 on success, or 1 on failure.
499 * Variables should be declared at the start of a block of code rather than in the middle.
500 …The exception to this is when the variable is ``const`` in which case the declaration must be at t…
503 …initializing variables in the declarations, only the last variable on a line should be initialized.
504 If multiple variables are to be initialized when defined, put one per line.
531 * Functions local to one source module should be declared static, and should not be prototyped unle…
532 * Functions used from other parts of code (external API) must be prototyped in the relevant include…
533 * Function prototypes should be listed in a logical order, preferably alphabetical unless there is …
536 * Functions that are part of an external API should be documented using Doxygen-like comments above…
546 * Short function prototypes should be contained on a single line.
547 Longer prototypes, e.g. those with many parameters, can be split across multiple lines.
548 …The second and subsequent lines should be further indented as for line statement continuations as …
565 * The function type should be on a line by itself preceding the function.
566 * The opening brace of the function body should be on a line by itself.
577 …Hiding file declarations in what appears to be a local scope is undesirable and will elicit compla…
578 * Old-style (K&R) function declaration should not be used, use ANSI function declarations instead a…
579 * Long argument lists should be wrapped as described above in the function prototypes section.
622 The error type should be indicated may setting the variable ``rte_errno`` appropriately.
626 * Where already standard in a given library, the alternative error approach may be used where the n…
628 * For functions where no error is possible, the function type should be ``void`` not ``int``.
637 * Values in return statements should not be enclosed in parentheses.
675 …ler builtin and allow the developer to indicate if the branch is likely to be taken or not. Exampl…
685 The use of ``likely()`` and ``unlikely()`` should only be done in performance critical paths,
687 These macros should be avoided in non-performance-critical code.
692 * All functions and variables that are local to a file must be declared as ``static`` because it ca…
693 * Functions that should be inlined should to be declared as ``static inline`` and can be defined in…
696 …Static functions defined in a header file must be declared as ``static inline`` in order to preven…
701 The ``const`` attribute should be used as often as possible when a variable is read-only.
706 The ``asm`` and ``volatile`` keywords do not have underscores. The AT&T syntax should be used.
707 Input and output operands should be named to avoid confusion, as shown in the following example:
742 logging of a particular topic, the ``--log-level`` parameter can be provided
768 logging output by using "specializations". A specialization could be the
771 An example could be the initialization log messages getting one
791 All Python code should be compliant with
794 The ``pep8`` tool can be used for testing compliance with the guidelines.
802 and should be added to the component lists in the ``meson.build`` files in the
809 The ``meson.build`` file for a new DPDK library should be of the following basic
822 For a library ``meson.build`` file, there are number of variables which can be
827 This variable should list out the files to be compiled up to create the
828 library. Files must be specified using the meson ``files()`` function.
837 also be set to explain to the user why the component is not being built.
838 A simple example of use would be:
850 Used to specify any additional cflags that need to be passed to compile
856 be assigned to using ``+=`` rather than overwriting using ``=``. The
857 dependencies should be specified as strings, each one giving the name of
862 variable may be omitted from the ``meson.build`` file. For example:
871 Used to specify external dependencies of this library. They should be
874 these, they should be checked to ensure the dependencies have been
875 found, and, if not, the ``build`` variable should be set to ``false``.
890 Used to return the list of header files for the library that should be
892 source files, these should be specified using the meson ``files()``
897 Used to indicate any additional header file paths which should be
902 it does not need to be specified here.
907 name, the name should be specified using this variable. In practice,
910 never be needed for new libraries.
916 library names differ, the ``version.map`` file should be named
921 This variable can be used to pass to the library build some pre-built
927 This variable should be used when a library is not to be built i.e. when
928 ``build`` is set to "false", to specify the reason why a library will not be
929 built. For missing dependencies this should be of the form
935 has, this value should be set to ensure that the C files are compiled
960 variable to allow the headers from that base directory to be found when
961 compiling driver sources. Should be appended to using ``+=`` rather than
962 overwritten using ``=``. The values appended should be meson include
980 libraries that may need to be linked into the build - especially when
981 using static libraries. Anything added here will be appended to the end