[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