Commit 7efaff34 authored by Alessandro Rubini's avatar Alessandro Rubini

doc: documented the configuration engine

Signed-off-by: Alessandro Rubini's avatarAlessandro Rubini <rubini@gnudd.com>
parent f0574f6b
......@@ -350,6 +350,51 @@ As of 2013-05 the project suffers from these known bugs:
untested in our environments.
@end itemize
@c ##########################################################################
@node Configuration
@chapter Configuration
PPSi support configuration files and individual configuration items
passed on the command line. Such support is currently not available
for freestanding architectures (the @i{bare} ones and @i{wrpc-sw}).
When PPSi starts it parses its own configuration. The command line can
include a number of @t{-f <file>} and @t{-C <item>} options; they are
processed in order, so later ones override earlier ones. A
configuration ``item'' can include several directives, using the
semicolon as a separator.
If no configuration file is specified, the program reads the default
one, which is architecture-specific (thus, the default configuration
file is processed after all the command line configuration items. The
default file name is @t{/etc/ppsi.conf}, but @t{arch-wrs} tries to
load @t{/wr/etc/ppsi.conf} first. The source tree of PPSi includes
two example configuration files in its own @t{etc/} subdirectory.
Configuration is made of of global options and port-specific options.
To configure a port, use @t{port <name>} followed by its options.
The parser allocates a new PTP state machine for each new port, but
allows changing configuration of an existing port. For instance, to
enable frame diagnostics for a specific port, you can use:
@smallexample
./ppsi -f /etc/ppsi.conf -C "port eth1; diagnostics 02"
@end smallexample
Each configuration item is made up of a keywork and an optional
argument. The argument can be either a number or a string. The
parser looks up keywords in three tables: a global table, an
architecture-specific table and an extension-specific table.
Currently not architectures or extensions provide configuration
keywords, while the list of global items is on show in @t{lib/conf.c},
as the @t{pp_global_arglines} array. Future versions of this manual
may document the keywords, if the time allows it.
@b{Note:} most current command-line options are going to be turned into
configuration options. This applies to the priorities, intervals and
thresholds, as well as the @i{slave-only} flag.
@c ##########################################################################
@node Diagnostics
@chapter Diagnostics
......@@ -357,10 +402,13 @@ As of 2013-05 the project suffers from these known bugs:
During development of PPSi, diagnostic support used several
techniques, but finally we converged on the one described here, that
is here to stay. The idea is that we need to add verbosity
per-feature and per-link. This fine-grained control is expected to be
per-feature and per-port. This fine-grained control is expected to be
important while developing features or while diagnosing problems on
new architectures.
The @t{diagnostics} configuration keyword can be used both as a global
item and as a port-specific configuration value.
@c ==========================================================================
@node Diagnostic Macros
@section Diagnostic Macros
......@@ -888,6 +936,10 @@ support since-char options; we don't want to rely on @i{getopt} which
is not available for all architectures, nor we want to implement
complex parsing.
@b{Note:} most current command-line options are going to be turned into
configuration options. This applies to the priorities, intervals and
thresholds, as well as the @i{slave-only} flag.
For standard operation, simply run @t{./ppsi} with no options. It will
work like the PTPd executable, with the automatic choice of
master/slave defined in @sc{ieee} specification (announce/timeout mechanism).
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment