[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evms-devel
Subject:    Re: [Evms-devel] More on engine debug output
From:       "Don Mulvey" <dlmulvey () us ! ibm ! com>
Date:       2001-07-23 16:46:04
[Download RAW message or body]

If it all comes down to logging then supporting dprintf in the engine is
really the simplest way to go.  I only conend that it is not the most
advantageous way to go.  Performance  is really  too long a discussion to
get into and much more interesting on the kernel side.    Later ...

-Don


Jason Ostermann <oddball@oddworld.org>@oddworld.org on 07/23/2001 04:36:48
PM

Sent by:  oddball@oddworld.org


To:   Don Mulvey/Austin/IBM@IBMUS
cc:
Subject:  Re: [Evms-devel] More on engine debug output



Don Mulvey wrote:
>
> I think your wrong.  Plugins are simple in nature.   Here is how simple a
> dprintf plugin would look like.   And I like the modular nature of
plugins.
> Some other group may wish to write their own logging plugin ... or ...
our
> performance dept may like to add performance counter support and high res
> timer support or dynamic hooks.    Consider this ... how would someone
> replace the engine's version of logging if it were built into the engine
> shared object?  I'd rather write a plugin than change the engine code.
My
> hunch is that a plugin is the right way to go ... even if it is really
too
> much work for the new dprintf.
>
[snip]
>
> Don Mulvey
> IBM Austin
> Linux Technology Center
> (512) 838-1787


OK, on the simplicity of the plugin I now agree. The whole
plugin/dynamic linking bit is quite new for me, so from my POV it is
still quite complicated.

I suppose the next question is how difficult is the engine side
implimentation of logging device plugin support? The engine will have to
load them, keep a list of availible logging devices, and send every
message to (I assume) every plugin. There would also need to be a
special API to configure the plugin (ie, output file, remote server (ie
output to a special port, say 25 to do email logging?), etc). then we
hit the wonderfull complexity of the task structure to deal with unknown
configuration options.
Ack?
The user would also need to be able to select which plugins are
"active". Most users will just compile everything they get, so they
could have, say, 6 live logging plugins. They only need to be able to
output to a local file. How do they turn off all the rest?
Also keeping in mind that this needs to be quick and simple for both the
user and the UI writer.
So default all=on wouldn't work too well. So now you need to be able to
selectivly turn them on.

I dunno. I think some things that could be done would be fun (that SMTP
email logging device has me thinking), but not too terribly usefull when
looking at the rest of the system that has to support it.

I suppose it comes down to "Are there possible logging requirements that
we cannot meet, and may wish to impliment at a later date?"
If we provide easy support for stdout, stderr, and arbitrary FILE*
(which can be alot more than just a file on a local harddrive), I'm not
seeing what else would be particularly usefull. If someone wants an odd
remote logging setup, they could easily write a wrapper around the
FILE*. Very easily in the client program, and still possible in
userspace.
Thankfully, the underlying system can do alot of wierd things for us, so
we don't really need to be ready for the kitchen sink - it's already
sitting right outside the door with the 10,000 other unix goodies.

The performance idea is an interesting one... But wouldn't that still
require massive support from the engine directly? and I'm probably
missing quite a bit, but I think that can be adequately done in
userspace with other utilities that 'watch' libevms, instead of libevms
doing it directly. and, of course, gcc has a fair bit of performance
debugging support.

[prev in list] [next in list] [prev in thread] [next in thread]