Changes: - Fix spelling errors (stystem -> system, acheived -> achieved) - Fix sentence structure for rte_log() parameter description - Use consistent spelling "timestamp" (one word)
Signed-off-by: Nandini Persad <[email protected]> Signed-off-by: Stephen Hemminger <[email protected]> --- doc/guides/prog_guide/log_lib.rst | 32 +++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/doc/guides/prog_guide/log_lib.rst b/doc/guides/prog_guide/log_lib.rst index 3e888b8965..a3d6104e72 100644 --- a/doc/guides/prog_guide/log_lib.rst +++ b/doc/guides/prog_guide/log_lib.rst @@ -6,7 +6,7 @@ Log Library The DPDK Log library provides the logging functionality for other DPDK libraries and drivers. By default, logs are sent only to standard error output of the process. -The syslog EAL option can be used to redirect to the stystem logger on Linux and FreeBSD. +The syslog EAL option can be used to redirect to the system logger on Linux and FreeBSD. In addition, the log can be redirected to a different stdio file stream. Log Levels @@ -26,14 +26,14 @@ These levels, specified in ``rte_log.h`` are (from most to least important): At runtime, only messages of a configured level or above (i.e. of higher importance) will be emitted by the application to the log output. -That level can be configured either by the application calling the relevant APIs from the logging library, +That level can be configured either by the application calling relevant APIs from the logging library, or by the user passing the ``--log-level`` parameter to the EAL via the application. Setting Global Log Level ~~~~~~~~~~~~~~~~~~~~~~~~ To adjust the global log level for an application, -just pass a numeric level or a level name to the ``--log-level`` EAL parameter. +pass a numeric level or a level name to the ``--log-level`` EAL parameter. For example:: /path/to/app --log-level=error @@ -47,9 +47,9 @@ Within an application, the log level can be similarly set using the ``rte_log_se Setting Log Level for a Component ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In some cases, for example, for debugging purposes, -it may be desirable to increase or decrease the log level for only a specific component, or set of components. -To facilitate this, the ``--log-level`` argument also accepts an, optionally wildcarded, component name, +In some cases (such as debugging purposes), +you may want to increase or decrease the log level for only a specific component or set of components. +To facilitate this, the ``--log-level`` argument also accepts an optionally wildcarded component name, along with the desired level for that component. For example:: @@ -57,13 +57,13 @@ For example:: /path/to/app --log-level=lib.*:warning -Within an application, the same result can be got using the ``rte_log_set_level_pattern()`` or ``rte_log_set_level_regex()`` APIs. +Within an application, the same result can be achieved by using the ``rte_log_set_level_pattern()`` or ``rte_log_set_level_regex()`` APIs. Using Logging APIs to Generate Log Messages ------------------------------------------- -To output log messages, ``rte_log()`` API function should be used. +To output log messages, the ``rte_log()`` API function should be used. As well as the log message, ``rte_log()`` takes two additional parameters: * The log level @@ -74,16 +74,16 @@ The component type is a unique id that identifies the particular DPDK component To get this id, each component needs to register itself at startup, using the macro ``RTE_LOG_REGISTER_DEFAULT``. This macro takes two parameters, with the second being the default log level for the component. -The first parameter, called "type", the name of the "logtype", or "component type" variable used in the component. -This variable will be defined by the macro, and should be passed as the second parameter in calls to ``rte_log()``. +The first parameter, called "type", is the name of the "logtype", or "component type" variable used in the component. +This variable will be defined by the macro and should be passed as the second parameter in calls to ``rte_log()``. In general, most DPDK components define their own logging macros to simplify the calls to the log APIs. They do this by: * Hiding the component type parameter inside the macro so it never needs to be passed explicitly. * Using the log-level definitions given in ``rte_log.h`` to allow short textual names to be used in - place of the numeric log levels. + place of numeric log levels. -The following code is taken from ``rte_cfgfile.c`` and shows the log registration, +The following code is taken from ``rte_cfgfile.c`` and shows the log registration and subsequent definition of a shortcut logging macro. It can be used as a template for any new components using DPDK logging. @@ -98,10 +98,10 @@ It can be used as a template for any new components using DPDK logging. it should be placed near the top of the C file using it. If not, the logtype variable should be defined as an "extern int" near the top of the file. - Similarly, if logging is to be done by multiple files in a component, - only one file should register the logtype via the macro, + Similarly, if logging will be done by multiple files in a component, + only one file should register the logtype via the macro and the logtype should be defined as an "extern int" in a common header file. - Any component-specific logging macro should similarly be defined in that header. + Any component-specific logging macro should be similarly defined in that header. Throughout the cfgfile library, all logging calls are therefore of the form: @@ -122,7 +122,7 @@ For example:: Multiple alternative timestamp formats are available: -.. csv-table:: Log time stamp format +.. csv-table:: Log timestamp format :header: "Format", "Description", "Example" :widths: 6, 30, 32 -- 2.51.0
