Hi, while our US colleagues are likely paralyzed from the annual Turkey massacre :-) I was busy to do some cleanup and add some stuff to the metrics.c files.
- moved the remaining arch dependant stuff from gmond to a header file in libmetrics. Now gmond is purely generic. Libmetrics is still kind of ugly. See the name of the new header file :-) - added stubs for the following metrics to those archs that did not have them: cpu_intr, cpu_sintr, bytes_in, bytes_out, pkts_in, pkts_out, disk_total, disk_free, part_max_used. The dummy metrics are not enabled, so nothing is actually changed for the reporting. The dummies are all marked "FIXME", so people with some time at their hands could try to fill them with content. - took some real stuff for Darwin from Sebastian Hagedorn. If we would make all mentioned metrics into core stuff, we would be clean of the ifdefs except for HPUX (some obscure mem stuff that I am responsible for, mem_[am,arm,vm,avm) and SOLARIS ([b,l,ph][read,write]). We could kill the HPUX stuff (its mine) and I have no real opinion about the SOLARIS data. The graphs do not look very interesting to me. Sometimes, maybe, one just has to let go ... But of course, that would bring some trouble with compatibility. As I discovered, and Matt confirmed, the mcast channel does not really like to deal with gmonds reporting different metrices. Similar for unicast. So, how to solve that? Why don't we bring some system to our release numbering scheme? We have "major.minor.sub", but we are not really using it. My proposal would be: - changes in "sub" are only bugfixes, tuning and "compatible" changes. As a result, a change in "sub" would not cause trouble on the mcast channel. New binaries would work with the same configuration files as older binaries with same "major.minor". Just drop them in. - changes in "minor" mean incompatibility. Either new metrices, or different behavior, cool new config syntax. A new "minor" release would mean that admins would have to upgrade all gmonds on their grids(s) to keep the mcast channel happy. - changes in "major" would mean real conceptual changes. Like the stuff that Matt has been talking about for a while now. What do you think? Matt? If we follow this scheme, we could declare 2.5.7 the "last" 2.5 cut and call the next release 2.6. I would activate the dummies for 2.6. Or we do 2.5.8 as the final 2.5 release (I would revert the cpu_wio changes to the 2.5.7 state to ensure compatibility) and follow up with 2.6 as above. If we don't implement this change, I would opt for going ahead with 2.5.8 as it is now, activating the dummies in 2.5.9 and live with the confusion. Cheers Martin ===== ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de
