Sounds good. I have the extensibility functionality at the point where I am able to define, build and load a module that implements a metric. A simple preliminary example of what the source for a module looks like is attached. As noted in the example source, I think that the module could be simplified even further once APR is linked dynamically. Using stack memory to return the info values seems a little dangerous and allocating the memory through malloc would require a cleanup callback to avoid a memory leak. APR memory management would handle it much cleaner. The directives in the gmond.conf for loading a module will be:
modules {
module {
name = "example_module"
path = "../lib/libmodexample.so"
}
module {
name = "other_module"
path = "../lib/libmodother.so"
}
...
}
I am still working on wiring the data gathered from a module into a form that
can be used by the gmond send functions without having to rely on the hardcoded
functions in protocol.x. When I am finished, it will probably work similar to
data gathered through gmetric. Anyway, I am hoping to have this all up and
working in the next couple of days. One big help in this effort would be if
somebody could rework the makefiles so that it linked APR dynamically rather
than statically.
thanks
Brad
>>> On 2/27/2007 at 10:09 AM, in message
<[EMAIL PROTECTED]>, matt massie <[EMAIL PROTECTED]>
wrote:
> brad-
>
> having loadable modules for gmond would be outstanding. one of the
> reason i moved gmond onto apr was for that very reason.
>
> there is no real reason for gmond to statically linked. it is mostly a
> historical artifact really. when ganglia was first written (back in
> 2000), package management was a nightmare. the feedback i got was that
> statically linking was favorable since it effectively eliminated most
> library dependencies.
>
> package management has come a long way in the last seven years so i
> think we should make static linking optional.
>
> the only other dependencies that ganglia has is to expat and libconfuse.
> the expat dependency could be easily dropped since apr has all the expat
> xml code.
>
> please let us know how we can help.
>
> On Tue, 2007-02-27 at 09:36 -0700, Brad Nicholes wrote:
>> I am working on adding metric module extensibility to gmond in much the
> same way that Apache loads and uses dynamic modules. The fact that APR
> already support DSO loading for various platforms, makes the Apache model an
> easy fit. While implementing the example metric module, I wondered why APR
> is linked statically to gmond rather than dynamically. Is there any specific
> reason? If gmond were to load APR dynamically, it would make it much easier
> for a metric module to also use APR especially for memory allocation. Also,
> once I have extensibility added, is the project interested in committing this
> feature back into the SVN repository?
>>
>> thanks,
>> Brad
>>
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Ganglia-developers mailing list
>> Ganglia-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ganglia-developers
mod_example.c
Description: Binary data
