From 6db6907c0ee87582845fd98932c22067a3b2b84f Mon Sep 17 00:00:00 2001 From: Rainer Gerhards Date: Fri, 21 Dec 2007 10:33:22 +0000 Subject: updated compatibiltiy notes according to latest state of the project --- doc/v3compatibility.html | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) 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.

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 ;)

+

command line options

+

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.

-m command line option

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

@@ -28,5 +32,31 @@ rsyslog.conf. That set of configuration directives is to be expanded. So far, we support:

$klogSymbolsTwice [on/off]
$DebugPrintKernelSymbols [on/off] # spits *a lot* of messages at startup

+

TODO List

+

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.

+

-c option

+

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.

+

Thread Termination

+

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.

+

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.

+

Call Encapsulation

+

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.

-- cgit