>>> On 7/3/2008 at 10:20 AM, in message <[EMAIL PROTECTED] , <[EMAIL PROTECTED]> wrote:
> >> > > Should a single module handle all architectures, or >> should there be >> > > a different module for each architecture? Also, does gmond have >> > > some way >> > >> > Ideally a single module should be able to handle all >> architectures. Practically, this may not be possible with >> some metrics. My guess is that for some modules like >> multi-disk, there will probably have to be different modules >> for each architecture or at least for architectures that are >> different enough to make it impractical for a single implementation. >> > > It would probably be sufficient to add an extra method to the module API > that can check whether the architecture is supported. The module > implementor could then decide whether they want their module to be > multi-architecture or single-architecture. > This should be done in the metric_init() function and if the architecture is not supported, then the function should not return any metric definitions. In fact for a multi-arch module, all that the metric_init() function would need to do is detect the architecture and then switch the actual metric_handler() callback to the appropriate handler for the architecture. Then the metric module would simply reimplement a metric_handler() for each architecture that it supports. This is basically what is being done for all of the standard metrics (cpu, memory, disk, network) today. The only difference is that the handler switch is happening at compile time rather than during the metric_init() because the standard metrics are all C interface modules. Brad ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
