On Thu, 26 Sep 2013, Rainer Gerhards wrote:
On Tue, Sep 24, 2013 at 8:00 PM, David Lang <[email protected]> wrote:
Rainer, is there an example of a simple module being converted to the new
config syntax?
I'm thinking that it would be useful to start collecting examples of
commits that do fairly simple things as documentation for programmers
trying to create/improve modules
a few of simple ones to start off with:
1. add a config parameter (I think I can dig this up from the imfile
changes where we implemented the multi-line mode)
I'll see if I can dig out something. But usually, there is more in a single
commit - because new params get added for new functionality and so this is
always intermixed.
If we can pick something that adds fairly trivial functionality, that would be
a good example.
2. change a new style parameter
I'm looking at omruleset and it looks like it may not support the new
config format yet, but I'm not sure. If it does, I'd like to understand how
it does, if not, it looks like it would be a tiny change and a good example
case
Actually not, because this is a deprecated module, carried within the
source tree just for backward compatibility. The "call" statement can do
anything omruleset does, but in a much higher performance way.
But I think ommail is also missing the new style config. I'll check and, if
so, it would make sense to convert it. When doing so, I could do baby-step
commits that show things being done individually.
Ok, I'm not easily finding documentation on 'call' (it's too common a word),
pointer please
3. how to manipulate the raw message buffer in parsing modules (I have
this archived in e-mail, I'll dig it up)
That's somewhat tricky at the moment and not properly encapsulated.
Important question: do you really mean rawmsg or just the msg part of the
message (rawmsg is even tricker due to the low-level optimizations made).
I was talking about rawmsg, the type of changes that I was doing in the cleanup
type parser modules (that tweak the incoming file to make it sane before letting
it fall through to a 'normal' parser)
What I'm hoping to generate here is a document that can become a 'getting
started hacking rsyslgo' guide that will show the right way to do some of these
things.
There is the template module code, which is a good start, but as I've learned
the hard way, adding functionality requires hooks elsewhere in the code, and I'm
thinking that the easiest way to document some of these things is just to point
to commits in git that add the right thing.
so when adding new optional functionality, you need to
1. implement the functionality
2. add the old-style parameter for it
3. add the new-style parameter for it
4. add the documentation for it
5. add a test for it
I don't think any of my contributions have gotten all of these right (or even
all except the new style parameters)
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
