updated compatibiltiy notes according to latest state of the project

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>