configs/fedora/generic/arm/CONFIG_EFI_VARS_PSTORE


1

CONFIG_EFI_VARS_PSTORE=y
<html>
<head>
<title>syslogd generic design</title>
</head>
<body>
<h2>Generic design of a syslogd</h2>
<p>Written 2007-04-10 by
<a href="http://www.adiscon.com/en/people/rainer-gerhards.php">Rainer Gerhards</a></p>
<p>The text below describes a generic approach on how a syslogd can be 
implemented. I created this description for some other project, where it was not 
used. Instead of throwing it away, I thought it would be a good addition to the 
rsyslog documentation. While rsyslog differs in details from the description 
below, it is sufficiently close to it. Further development of rsyslog will 
probably match it even closer to the description.</p>
<p>If you intend to read the rsyslog source code, I recommend reading this 
document here first. You will not find the same names and not all of the 
concepts inside rsyslog. However, I think your understanding will benefit from 
knowing the generic architecture.</p>
<font size="3"><pre>

   +-----------------+
   | "remote" PLOrig |
   +-----------------+
       |
       I  +--------+-----+-----+          +-----+-------+------+-----+
       P  | PLOrig | GWI | ... |          | GWO | Store | Disc | ... |
       C  +--------+-----+-----+          +-----+-------+------+-----+
       |        |                                          ^
       v        v                                          |
      +--------------+        +------------+          +--------------+
      | PLGenerator  |        |  RelayEng  |          | CollectorEng |
      +--------------+        +------------+          +--------------+
             |                      ^                       ^
             |                      |                       |
             v                      v                       |
      +-------------+         +------------+          +--------------+
      |   PLG Ext   |         | RelEng Ext |          | CollcEng Ext |
      +-------------+         +------------+          +--------------+
             |                      ^                       ^
             |                      |                       |
             v                      v                       |
      +--------------------------------------------------------------+
      |                      Message Router                          |
      +--------------------------------------------------------------+
                         |                            ^
                         v                            |
      +--------------------------------------------------------------+
      |           Message CoDec (e.g. RFC 3164, RFCYYYY)             |
      +--------------------------------------------------------------+
                         |                            ^
                         v                            |
      +---------------------+-----------------------+----------------+
      |    transport UDP    |    transport TLS      |      ...       |
      +---------------------+-----------------------+----------------+

                Generic Syslog Application Architecture
</pre></font>
<ul>
	<li>A &quot;syslog application&quot; is an application whose purpose is the
processing of syslog messages. It may be part of a larger
application with a broader purpose. An example: a database
application might come with its own syslog send subsystem and not
go through a central syslog application. In the sense of this
document, that application is called a &quot;syslog application&quot; even
though a casual observer might correctly call it a database
application and may not even know that it supports sending of
syslog messages.</li>
	<li>Payload is the information that is to be conveyed. Payload by
itself may have any format and is totally independent from to
format specified in this document. The &quot;Message CoDec&quot; of the
syslog application will bring it into the required format.</li>
	<li>Payload Originators (&quot;PLOrig&quot;) are the original creators of payload.
Typically, these are application programs.</li>
	<li>A &quot;Remote PLOrig&quot; is a payload originator residing in a different
application than the syslog application itself. That application
may reside on a different machine and may talk to the syslog
application via RPC.</li>
	<li>A &quot;PLOrig&quot; is a payload originator residing within the syslog
application itself. Typically, this PLOrig emits syslog
application startup, shutdown, error and status log messages.</li>
	<li>A &quot;GWI&quot; is a inbound gateway. For example, a SNMP-to-syslog
gateway may receive SNMP messages and translate them into syslog.</li>
	<li>The ellipsis after &quot;GWI&quot; indicates that there are potentially a
variety of different other ways to originally generate payload.</li>
	<li>A &quot;PLGenerator&quot; is a payload generator. It takes the information
from the payload-generating source and integrates it into the
syslog subsystem of the application. This is a highly theoretical
concept. In practice, there may not actually be any such
component. Instead, the payload generators (or other parts like
the GWI) may talk directly to the syslog subsystem. Conceptually,
the &quot;PLGenerator&quot; is the first component where the information is
actually syslog content.</li>
	<li>A &quot;PLG Ext&quot; is a payload generator extension. It is used to
modify the syslog information. An example of a &quot;PLG Ext&quot; might be
the addition of cryptographic signatures to the syslog
information.</li>
	<li>A &quot;Message Router&quot; is a component that accepts in- and outbound
syslog information and routes it to the proper next destination
inside the syslog application. The routing information itself is
expected to be learnt by operator configuration.</li>
	<li>A &quot;Message CoDec&quot; is the message encoder/decoder. The encoder
takes syslog information and encodes them into the required format<br>for a syslog message. The decoder takes a syslog message and
decodes it into syslog information. Codecs for multiple syslog
formats may be present inside a single syslog application.</li>
	<li>A transport (UDP, TLS, yet-to-be-defined ones) sends and receives
syslog messages. Multiple transports may be used by a single<br>syslog application at the same time. A single transport instance
may be used for both sending and receiving. Alternatively, a
single instance might be used for sending and receiving
exclusively. Multiple instances may be used for different
listener ports and receivers.</li>
	<li>A &quot;RelayEng&quot; is the relaying engine. It provides functionality
necessary for receiving syslog information and sending it to
another syslog application.</li>
	<li>A &quot;RelEng Ext&quot; is an extension that processes syslog information
as it enters or exits a RelayEng. An example of such a component
might be a relay cryptographically signing received syslog