Re: [Evms-devel] More on engine debug output

[Don M. <dlm...@us...>]

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.


static int Setup( EngineMode mode, struct EVMS_Engine_Functions
*engine_function_table )
{
     return 0;
}

static int dprintf( char *message)
{
     return DPRINTF(("%s",message));
}

static struct Logging_functions fncs = {
     SetupEvmsPlugin:    Setup,
     dprintf:            dprintf
};

int PluginInit( Plugin_Record *pPlugRec )
{
     pPlugRec->short_name = "EvmsLogger";
     pPlugRec->long_name = "Evms Logging Service";
     pPlugRec->oem_name = "IBM";
     pPlugRec->major_version = CURRENT_EVMS_MAJOR_VERSION_NUMBER:
     pPlugRec->minor_version = CURRENT_EVMS_MINOR_VERSION_NUMBER:
     pPlugRec->function_table = (void *) &fncs;
     pPlugRec->id = EVMS_PLUGIN_ID(EVMS_OEM_IBM,  EVMS_LOGGING_SERVICE,
EVMS_IBM_DPRINTF_ID );
}

void PluginCleanup( Plugin_Record * pPlugRec
{
}

Don Mulvey
IBM Austin
Linux Technology Center
(512) 838-1787


Jason Ostermann <od...@od...>@lists.sourceforge.net on 07/22/2001
10:22:10 PM

Sent by:  evm...@li...


To:   evm...@li...
cc:
Subject:  [Evms-devel] More on engine debug output



First a bit on the distributed problem:
I think this is going to be highly dependent on how the remote
management is handled. In the case where you run the engine remotely and
export/ssh the display, there's no problem - it gets dumped right where
the user expects. In the case of a remote daemon that handles the
hardware (ie, a replacement of LocalDiskManager, something like
RemoteDiskManager) calls... well, that will have to communicate errors
(which I assume would only be on device read/write) back to the client
that invoked it, and the client would have to handle it from there.
I'm sure that's still leaving holes the size of small icebergs.

Don:
I'm not too clear on the logging plugin idea. Is there enough
functionality to justify a full plugin? With all the changes I'm
currently thinking about, there shouldn't be more than 100 lines of
code. We'd have to do some awfully complex logging, IMO, to make a
plugin worthwhile.
As far as deadly errors, I think that the printf() should be changed to
use the logging functionality, and the rc should be the "message index".


Now, for my current half-baked idea:
change OpenEVMSEngine to OpenEVMSEngine(enginemode, debug_level,
debug_log_device)
debug_level is a bitmask, probably needing int32 for that, and
debug_log_device is a FILE*.
debug_level can select both sources to filter and levels. ie,
SRC_ENGINE, SRC_PLUGINS, DEBUG_WARN, DEBUG_ABEND, DEBUG_INFO, etc.
That can also be expanded such that each plugin has it's own bit - very
fine granularity. I think an int32 would still leave enough room for
that without driving everyone insane. Of course, you'd still want an
"ALL" flag.
debug_log_device is the FILE* that the UI program wants messages sent
to. stdio.h defines stdout and stderr for us, so you can do:
OpenEVMSEngine(EVMS_god_mode,OUTPUT_ALL,stdout) - would be equivalent to
what we do today.
Or, the user can pop open a file and hand us the FILE*, which we will
dump things to, and then leave it open for them to close after the
CloseEVMSEngine().

Currently, change DPRINTF from a define to a function in engine.c. I'm
not sure about the issues of scope for the bitmask/device. Someone with
more C knowledge than me will have to figure that one out. I guess that
at worst, we need helpers in engine.c that returns the relevant info.
IOW, we don't want to burden the plugin with keeping track of the debug
bitmask and device. Anyway, leave the user-side of DPRINTF the same so
we don't have to bother trying to change all of our code tonight. But,
expand it's functionality to go to the log device instead of using
printf's.

In the near future, move over to DLOG(PROVIDER_BITMASK,message), where
PROVIDER_BITMASK is the bitmask for the program sending the message, ie
SRC_PLUGIN_LVMREGMGR|DEBUG_INFO|DEBUG_WARN. DLOG isn't used by anyone
(well, a quick grep didn't show anything interesting), so we can migrate
to that as people have a chance.

Of course, DLOG would check the bitmasks to see whether or not the
message should be output, and if it is, send it to the provided log
device.

The easy #ifdef DEBUG ... #endif can stay, so that if debug support
isn't chosen at compile time, there will be no debug output no matter
what OpenEVMSEngine says (problem: user may be confused by this, but I'd
consider them numbskulls in that case).


Quick problems that I see: what if the user drops in an invalid FILE*? I
guess we'd have to stat it first, and set it to null if it's invalid. In
the case of log_device==null, don't output anything. Well, maybe a
printf() notifying the user of the problem? =)

So, does this sound any closer to useful?

_______________________________________________
Evms-devel mailing list
Evm...@li...
http://lists.sourceforge.net/lists/listinfo/evms-devel