[evlog-dev] Re: Backend patch proposal
Hien Nguyen <[email protected]> Tue, 20 Apr 2004 10:15:35 -0700
| Newsgroups | gmane.linux.kernel.event-logging |
|---|---|
| Message-ID | <[email protected]> |
Hello Benoit, Thanks for the patch, it looks good. I will do some testing and check in the changes.=20 On Tue, 2004-04-20 at 05:18, Benoit Guillon wrote: > Hello Hien,=20 > =20 > > > I'm sorry to bother you again, but I have some questions about the > > > evlog implementation (1.0.6-b2) and its scope:=20 > > >=20 > >=20 > > No problem, I am glad that you are still with us :-) > Thanks :-)=20 > > > * Is it necessary to fork evlogd to manage kernel events? [...]=20 > >=20 > > We have to use either a separate process (via fork) or a separate=20 > > thread, because the code that drains the kernel buffer can't use=20 > > select() or poll(). We avoided implementing stuff using threads > > because=20 > > it wasn't clear that POSIX threads would find their way into > > standard=20 > > Linux. Also, I'm not sure whether do_syslog() is (or needs to be)=20 > > thread-aware. > Ok. That's fun to see that you implement a withdrawn POSIX standard > and that you care about using the well established POSIX threads ;-)=20 > > > * As far as I can understand, all the backends are called for each > > > event. [...]=20 > >=20 > > The current design sends all events that go to the log file to=20 > > backends. One could write a backend to filter out some events and > > only=20 > > route some specified events. If you are interesting in writing one, > > I=20 > > could give some helps. > Don't you think it costs very much to call each backend, and each > backend would need a filter to check if it can process the event? This > is why I suggested to select the backend before its call.=20 evlogd does filter out events (one could use 'evlconfig -s filter' to screen out events), only events that go to the log file reach the backends. But the idea of selecting a backend base on its filter before its call is certainly very interesting. Would each backend have its own filter in the conf file? > > > It is not possible if the TCP backend is used for all the events. > >=20 > > I am not sure I understand this question, but TCP backend is used to > > forward all events that go to the log file to a remote host. > Yep. In fact the sentence was only the end of the previous question > ;-)=20 > > > * Is it possible to use IBM Director combined to evlog ELA > > feature, or=20 > > > is IBM Director techno incompatible?=20 > >=20 > > We are currently working with IBM Director experts on the > > integration of=20 > > evlog Error Log Analysis with IBM Director. > That's promising!=20 >=20 > Now, I change the subject. I propose to change the backend interface, > to make it simpler. The principle is not to have predefined functions > names (by the way, why the processing func isn't a predefined name > itself?) but it is to have a backend descriptor that would contain all > its methods (and some attributes if needed, such like its name). The > backend loading just consists in obtaining the descriptor address and > then calling its functions. The advantages are:=20 >=20 > * only one symbol to resolve,=20 > * plugins initialization easier,=20 > * plugin modularity increased (the methods can be static),=20 > * plugin interface clearly defined (descriptor set),=20 > * the model can be extended: new methods or plugin attributes can be > added to the backend descriptor.=20 >=20 > The other changes I suggest :=20 > * be_init() returns the plugins found so that be_cnt doesn't need to > be plublic,=20 > * be_release() works directly on backend_t object; there is no reason > to make it find the backen to release since it is an internal > function,=20 > * the callback is passed when initializing the plugin. I don't see why > a specific func should be called to pass the callback (besides, 2 > functions involve a correct order call).=20 >=20 > I attach the changes made, if it can be of some use. Please don't > blame me if there are some subtilities in the original implementation > that I haven't seen!=20 >=20 > Bye,=20 > -- > Beno=C3=AEt Guillon [email protected]=20 Thanks again. ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click