2007/12/17, Rainer Gerhards <[EMAIL PROTECTED]>: > Hi all, > > I would appreciate your feedback on backward compatibility. I have > started to create a loadable input module interface in rsyslog v3. My > first input module is the mark message handler (because it has almost no > code, so it was a good example of what needs to be done...). I have now > basically have finished an initial version. The interface needs to be > changed in the longer term, but I'll postpone that until I've done a bit > more work on the config interface. Now I am facing a problem with > backward compatibility: > > In sysklogd/rsyslog pre-v3, the -m option controls how often mark > messages are written (with -m0 disabling this mechanism). In v3, the
One thing I was wondering: If you intend to shift all (even core) functionality into loadable modules, how do do you handle things like --help or available command line options like -m Do you want to hardcode it or will you provide an interface, where rsyslog will query the module about its help message and available options. I'm also still a bit uncertain, if moving everything resp. core functionality to modules is a good idea (for problems you already mentioned). Imho having all core functionality in a single binary is simply much more robust and fool proof. For things like the SQL db output plugin, the module interface is great, because it avoids to pull in large library and package dependencies and allows to install them on a as need basis. For other functionality I still need to recognize the benefits. Rainer, could you roughly sketch, how you envision to break rsyslog into loadable modules in v3. Which kind of functionality would be loadable as module, which functionality do you plan to keep in the rsyslogd binary. A listing of all (planned) modules + the provided functionality and requirements would really help. Another thing: Say you move the regexp support into a separate module. If a regexp is then used in rsyslog.conf, will you bail out with an error, simply print a warning (which could go unnoticed and the poor administrator doesn't know why his regexp doesn't know) or load modules on demand. For the latter you'd need some kind of interface to query the *.so files for their supported functionality. I.e. the modules would export a list of config directives it supports and rsyslog could upon startup query each available module and create a map. So, e.g. the ommysql module would export its support for the :ommysql: config directive. Whenever rsyslog finds such a config directive it could/would load the modules on demand. Same could be done for the command line parameters. The imklog module would export, that it supports the -m command line parameter. Whenever that commandline parameter is used, rsyslog would know which module to load. There are only rough ideas and there is certainly still much to consider. But what do you think about the basic idea? Cheers, Michael Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog
