- * This section describes the API to the log functions used
- * everywhere in this project.
-
-\section XBT_log_toc Table of contents
-
- - \ref log_overview
- - \ref log_cat
- - \ref log_pri
- - \ref log_app
- - \ref log_hist
- - \ref log_API
- - \ref log_API_cat
- - \ref log_API_pri
- - \ref log_API_subcat
- - \ref log_API_easy
- - \ref log_API_example
- - \ref log_user
- - \ref log_use_conf
- - \ref log_use_misc
- - \ref log_internals
- - \ref log_in_perf
- - \ref log_in_app
- - \ref XBT_log_cats
-
-\section log_overview 1. Introduction
-
-This module is in charge of handling the log messages of every SimGrid
-program. The main design goal are:
-
- - <b>configurability</b>: the user can choose <i>at runtime</i> what messages to show and
- what to hide, as well as how messages get displayed.
- - <b>ease of use</b>: both to the programmer (using preprocessor macros black magic)
- and to the user (with command line options)
- - <b>performances</b>: logging shouldn't slow down the program when turned off, for example
- - deal with <b>distributed settings</b>: SimGrid programs are [often] distributed ones,
- and the logging mecanism allows to syndicate each and every log source into the same place.
- At least, its design would allow to, once we write the last missing pieces
-
-There is three main concepts in SimGrid's logging mecanism: <i>category</i>,
-<i>priority</i> and <i>appender</i>. These three concepts work together to
-enable developers to log messages according to message type and priority, and
-to control at runtime how these messages are formatted and where they are
-reported.
-
-\subsection log_cat 1.1 Category hierarchy
-
-The first and foremost advantage of any logging API over plain printf()
-resides in its ability to disable certain log statements while allowing
-others to print unhindered. This capability assumes that the logging space,
-that is, the space of all possible logging statements, is categorized
-according to some developer-chosen criteria.
-
-This observation led to choosing category as the central concept of the
-system. In a certain sense, they can be considered as logging topics or
-channels.
-
-\subsection log_pri 1.2 Logging priorities
-
-The user can naturally declare interest into this or that logging category, but
-he also can specify the desired level of details for each of them. This is
-controled by the <i>priority</i> concept (which should maybe be renamed to
-<i>severity</i>).
-
-Empirically, the user can specify that he wants to see every debuging message
-of GRAS while only being interested into the messages at level "error" or
-higher about the XBT internals.
-
-\subsection log_app 1.3 Message appenders
-
-The message appenders are the elements in charge of actually displaying the
-message to the user. For now, there is only one appender: the one able to print
-stuff on stderr. But everything is in place internally to write new ones, such
-as the one able to send the strings to a central server in charge of
-syndicating the logs of every distributed daemons on a well known location.
-
-It should also be possible to pass configuration informations to the appenders,
-specifying for example that the message location (file and line number) is only
-relevant to debugging information, not to critical error messages.
-
-One day, for sure ;)
-
-\subsection log_hist 1.4 History of this module
-
-Historically, this module is an adaptation of the log4c project, which is dead
-upstream, and which I was given the permission to fork under the LGPL licence
-by the log4c's authors. The log4c project itself was loosely based on the
-Apache project's Log4J, which also inspired Log4CC, Log4py and so on. Our work
-differs somehow from these projects anyway, because the C programming language
-is not object oriented.
-
-\section log_API 2. Programmer interface
-
-\subsection log_API_cat 2.1 Constructing the category hierarchy
-
-Every category is declared by providing a name and an optional
-parent. If no parent is explicitly named, the root category, LOG_ROOT_CAT is
-the category's parent.
-
-A category is created by a macro call at the top level of a file. A
-category can be created with any one of the following macros:
-
- - \ref XBT_LOG_NEW_CATEGORY(MyCat,desc); Create a new root
- - \ref XBT_LOG_NEW_SUBCATEGORY(MyCat, ParentCat,desc);
- Create a new category being child of the category ParentCat
- - \ref XBT_LOG_NEW_DEFAULT_CATEGORY(MyCat,desc);
- Like XBT_LOG_NEW_CATEGORY, but the new category is the default one
- in this file
- - \ref XBT_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, ParentCat,desc);
- Like XBT_LOG_NEW_SUBCATEGORY, but the new category is the default one
- in this file
-
-The parent cat can be defined in the same file or in another file (in
-which case you want to use the \ref XBT_LOG_EXTERNAL_CATEGORY macro to make
-it visible in the current file), but each category may have only one
-definition.
-
-Typically, there will be a Category for each module and sub-module, so you
-can independently control logging for each module.
-
-For a list of all existing categories, please refer to the \ref XBT_log_cats
-section. This file is generated automatically from the SimGrid source code, so
-it should be complete and accurate.
-
-\section log_API_pri 2.2 Declaring message priority
-
-A category may be assigned a threshold priorty. The set of priorites are
-defined by the \ref e_xbt_log_priority_t enum. All logging request under
-this priority will be discarded.
-
-If a given category is not assigned a threshold priority, then it inherits
-one from its closest ancestor with an assigned threshold. To ensure that all
-categories can eventually inherit a threshold, the root category always has
-an assigned threshold priority.
-
-Logging requests are made by invoking a logging macro on a category. All of
-the macros have a printf-style format string followed by arguments. If you
-compile with the -Wall option, gcc will warn you for unmatched arguments, ie
-when you pass a pointer to a string where an integer was specified by the
-format. This is usualy a good idea.
-
-Because some C compilers do not support vararg macros, there is a version of
-the macro for any number of arguments from 0 to 6. The macro name ends with
-the total number of arguments.
-
-Here is an example of the most basic type of macro. This is a logging
-request with priority <i>warning</i>.
-
-<code>CLOG5(MyCat, gras_log_priority_warning, "Values are: %d and '%s'", 5,
-"oops");</code>
-
-A logging request is said to be enabled if its priority is higher than or
-equal to the threshold priority of its category. Otherwise, the request is
-said to be disabled. A category without an assigned priority will inherit
-one from the hierarchy.
-
-It is possible to use any non-negative integer as a priority. If, as in the
-example, one of the standard priorites is used, then there is a convenience
-macro that is typically used instead. For example, the above example is
-equivalent to the shorter:
-
-<code>CWARN4(MyCat, "Values are: %d and '%s'", 5, "oops");</code>
-
-\section log_API_subcat 2.3 Using a default category (the easy interface)
-
-If \ref XBT_LOG_NEW_DEFAULT_SUBCATEGORY(MyCat, Parent) or
-\ref XBT_LOG_NEW_DEFAULT_CATEGORY(MyCat) is used to create the
-category, then the even shorter form can be used:
-
-<code>WARN3("Values are: %d and '%s'", 5, "oops");</code>
-
-Only one default category can be created per file, though multiple
-non-defaults can be created and used.
-
-\section log_API_easy 2.4 Putting all together: the easy interface
-
-First of all, each module should register its own category into the categories
-tree using \ref XBT_LOG_NEW_DEFAULT_SUBCATEGORY.
-
-Then, logging should be done with the DEBUG<n>, VERB<n>, INFO<n>, WARN<n>,
-ERROR<n> or CRITICAL<n> macro families (such as #DEBUG10, #VERB6,
-#INFO8, #WARN6, #ERROR6 and #CRITICAL6). For each group, there is at
-least 6 different macros (like DEBUG0, DEBUG1, DEBUG2, DEBUG3, DEBUG4 and
-DEBUG5), only differing in the number of arguments passed along the format.
-This is because we want SimGrid itself to keep compilable on ancient
-compiler not supporting variable number of arguments to macros. But we
-should provide a macro simpler to use for the users not interested in SP3
-machines (FIXME).
-
-Under GCC, these macro check there arguments the same way than printf does. So,
-if you compile with -Wall, the folliwing code will issue a warning:
-<code>DEBUG2("Found %s (id %f)", some_string, a_double)</code>
-
-If you want to specify the category to log onto (for example because you
-have more than one category per file, add a C before the name of the log
-producing macro (ie, use #CDEBUG10, #CVERB6, #CINFO8, #CWARN6, #CERROR6 and
-#CCRITICAL6 and friends), and pass the category name as first argument.
-
-The TRACE priority is not used the same way than the other. You should use
-the #XBT_IN, XBT_IN<n> (up to #XBT_IN5), #XBT_OUT and #XBT_HERE macros
-instead.
-
-\section log_API_example 2.5 Example of use
-
-Here is a more complete example:
-
-\verbatim
-#include "xbt/log.h"
-
-/ * create a category and a default subcategory * /
-XBT_LOG_NEW_CATEGORY(VSS);
-XBT_LOG_NEW_DEFAULT_SUBCATEGORY(SA, VSS);
-
-int main() {
- / * Now set the parent's priority. (the string would typcially be a runtime option) * /
- xbt_log_control_set("SA.thresh:3");
-
- / * This request is enabled, because WARNING >= INFO. * /
- CWARN2(VSS, "Low fuel level.");
-
- / * This request is disabled, because DEBUG < INFO. * /
- CDEBUG2(VSS, "Starting search for nearest gas station.");
-
- / * The default category SA inherits its priority from VSS. Thus,
- the following request is enabled because INFO >= INFO. * /
- INFO1("Located nearest gas station.");
-
- / * This request is disabled, because DEBUG < INFO. * /
- DEBUG1("Exiting gas station search");
-}
-\endverbatim
-
-
-\section log_user 3. User interface
-
-\section log_use_conf 3.1 Configuration
-Configuration is typically done during program initialization by invoking
-the xbt_log_control_set() method. The control string passed to it typically
-comes from the command line. Look at the documentation for that function for
-the format of the control string.
-
-Any SimGrid program can furthermore be configured at run time by passing a
---xbt-log argument on the command line (--gras-log, --msg-log and --surf-log
-are synonyms provided by aestheticism). You can provide several of those
-arguments to change the setting of several categories, they will be applied
-from left to right. So,
-\verbatim --xbt-log="root.thres:debug root.thres:critical"\endverbatim
-should disable any logging.
-
-Note that the quotes on above line are mandatory because there is a space in
-the argument, so we are protecting ourselves from the shell, not from SimGrid.
-We could also reach the same effect with this:
-\verbatim --xbt-log=root.thres:debug --xbt-log=root.thres:critical\endverbatim
-
-\section log_use_misc 3.2 Misc and Caveats
-
- - Do not use any of the macros that start with '_'.
- - Log4J has a 'rolling file appender' which you can select with a run-time
- option and specify the max file size. This would be a nice default for
- non-kernel applications.
- - Careful, category names are global variables.
-
-\section log_internals 4. Internal considerations
-
-This module is a mess of macro black magic, and when it goes wrong, SimGrid
-studently loose its ability to explain its problems. When messing around this
-module, I often find useful to define XBT_LOG_MAYDAY (which turns it back to
-good old printf) for the time of finding what's going wrong.
-
-\section log_in_perf 4.1 Performance
-
-Except for the first invocation of a given category, a disabled logging request
-requires an a single comparison of a static variable to a constant.
-
-There is also compile time constant, \ref XBT_LOG_STATIC_THRESHOLD, which
-causes all logging requests with a lower priority to be optimized to 0 cost
-by the compiler. By setting it to gras_log_priority_infinite, all logging
-requests are statically disabled and cost nothing. Released executables
-might be compiled with
-\verbatim-DXBT_LOG_STATIC_THRESHOLD=gras_log_priority_infinite\endverbatim
-
-Compiling with the \verbatim-DNLOG\endverbatim option disables all logging
-requests at compilation time while the \verbatim-DNDEBUG\endverbatim disables
-the requests of priority below INFO.
-
-\todo Logging performance *may* be improved further by improving the message
-propagation from appender to appender in the category tree.
-
-\section log_in_app 4.2 Appenders
-
-Each category has an optional appender. An appender is a pointer to a
-structure which starts with a pointer to a doAppend() function. DoAppend()
-prints a message to a log.
-
-When a category is passed a message by one of the logging macros, the
-category performs the following actions:
-
- - if the category has an appender, the message is passed to the
- appender's doAppend() function,
- - if additivity is true for the category (which is the case by
- default, and can be controlled by xbt_log_additivity_set()), the
- message is passed to the category's parent.
-
-By default, only the root category have an appender, and any other category has
-its additivity set to true. This causes all messages to be logged by the root
-category's appender.
-
-The default appender function currently prints to stderr, and no other one
-exist, even if more would be needed, like the one able to send the logs to a
-remote dedicated server, or other ones offering different output formats.
-This is on our TODO list for quite a while now, but your help would be
-welcome here, too.
-
-
-*/