Announcements :: Honey, I shrunk the syslogd... :: (584 Reads)
Posted by
rgerhards
on Friday, July 27, 2007 - 03:08 AM
Have you noticed it? Syslogd.c is shrinking these days...
Ever since I started to work on this project, syslogd.c kept growing. Rsyslog was forked from sysklogd quite a while ago. I inherited working code, that enabled me to build an enhanced syslogd step by step. However, what I also inherited was a monolithic design. In the early days, that was not really an issue. Sysklogd's syslogd is roughly 2000 lines of code and lots of it is the version history in comments.
As I built on that basis, more and more features were added. Some of these features required supporting functions. Some of them were implemented in separate source files. The majority of the code, though, went straight into syslogd.c. A major reason for this was that moving the code to some more decent place would have required re-working of the code. And, hey, who would do that when you can otherwise implement the next cool and ever-requested feature. So this went on and on and syslogd.c kept growing. What I managed to do, at least, was to build blocks, delimited by comments, inside syslogd.c. That should later turn out to be a life-saver. But while the code for different modules was somewhat clean to identify, it used global data structures all the way long. Anyhow, all worked well...
In July of 2007, we finally hit the mark of over 10,000 lines of code for syslogd.c - and this even after some of the defines were already moved out of the main code file. Of course, many of these lines are comments (I am proud that rsyslog is probably one of the best-commented open source packages out). And of course 10,000 lines is not much - but after all, it is still a small project, and for that a single file of that size is scary.
That alone would not have me convinced to give up my lazyness. However, new feature request came in. A plug-in interface would be nice. And, while we are at it, how about queued message delivery in case the recipient is not available? And what about an even enhanced multi-threading that will support tomorrow's highly parallel many-many core CPUs? There are good answers to all of these questions. It's even fun to do. But not with the original monolithic design. No, that's a no-go. Can't do. Ummm.., OK, will not do ;)
...sorry folks - I run out of time right now. Will be continued...
Only logged in users are allowed to comment.
register/log in
