summaryrefslogtreecommitdiffstats
path: root/doc/v3compatibility.html
diff options
context:
space:
mode:
Diffstat (limited to 'doc/v3compatibility.html')
-rw-r--r--doc/v3compatibility.html30
1 files changed, 30 insertions, 0 deletions
diff --git a/doc/v3compatibility.html b/doc/v3compatibility.html
index 7c372162..71ee5dc7 100644
--- a/doc/v3compatibility.html
+++ b/doc/v3compatibility.html
@@ -14,6 +14,10 @@ both in regard to sysklogd and rsyslog v1 and v2.</P>
be resolved, so be sure to check back often. Also, comments and suggestions are
appreciated. Feedback right in time can now have a big impact on the route we
take ;)</P>
+<h2>command line options</h2>
+<p>A number of command line options have been removed. New config file
+directives have been added for them. Once we implement compatibiltiy mode, these
+options will return, but only if running in non-v3-native mode.</p>
<h2>-m command line option</h2>
<P>The -m command line option is ignored for the time being. There is no default
mark period. If you need a 20 minute mark period you need to</P>
@@ -28,5 +32,31 @@ rsyslog.conf. That set of configuration directives is to be expanded. So far, we
support:</P>
<P>$klogSymbolsTwice [on/off]<br>
$DebugPrintKernelSymbols [on/off] # spits *a lot* of messages at startup</P>
+<h1>TODO List</h1>
+<P>I have decided to move the todo list for v3 also into this document. After
+all, it is kind of a compatibility issue ;) But, more seriously, I think this is
+a good place to make sure nothing is forgotten. Remember that as of now, rsyslog
+v3 is in its early stage of development and so there definitely are some nits
+that will give you grief. This section here tells you what it is.</P>
+<h2>-c option</h2>
+<P>needs to be implemented. So far, only -c3 is supported. Everything else does
+not change anything but just provides a warning message. In short: there is no
+backwards compatibility yet.</P>
+<h2>Thread Termination</h2>
+<p>Thread termination in mode 1 needs to be looked at. I begin to think that it
+is OK if we simply cancel the thread, because we already have a different
+cleanup function. Otherwise, there is a potential for a race condition after we
+unblocked the TermOK mutex but before select() is entered. If the signal then
+occurs, we may have a problem. However, I would like to create the other input
+modules first so that I have more working experience with termination
+requirements. Again, I think this will lead to changes in thread termination.</p>
+<p>So far, this issue is resolved, but there is still some code present that
+needs to go away (right now disabled). I keep it in because I will make the
+final decision based on experience gained during creation of input modules.</p>
+<h2>Call Encapsulation</h2>
+<p>In an ideal world, the modules should call back only to some well-defined and
+specifically exported interface functions. Right now, we do not have an ideal
+world and the input modules make some calls back into the core. This needs to be
+re-thought but is accepted for the time being.</p>
</body>
</html>