diff options
| -rw-r--r-- | doc/v3compatibility.html | 30 |
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> |