[Freeipmi-devel] tmpl_get_sensor_discrete_reading_rs changes

[Albert Chu]

I have some issues with the changes made below in
tmpl_get_sensor_discrete_reading_rs:

    {15, "sensor_state"},
/*     {1, "state_0_asserted"},  */
/*     {1, "state_1_asserted"},  */
<snip>
/*     {1, "state_13_asserted"},  */
/*     {1, "state_14_asserted"},  */

1) I'm not sure about everyone else, but I have tried very hard to
define fiid_template_t templates based on the definitions in the IPMI
specification.  The changes above remove the IPMI specification
definitions out of the template.

2) In ipmi_get_generic_event_message_list() and
ipmi_get_event_message_list(), there are loops like this:

  for (offset = 0; offset < 16; offset++)
    {
      bit = pow (2, offset);
      if (sensor_state & bit)
        {
          message_list[i] = ipmi_get_event_message (sensor_type_code,
offset);
          if (message_list[i])
            i++;
        }
    }

I believe the above is one of the reasons why we defined template fields
very closely to the IPMI specification.  We wanted to avoid constant
bit-masking in favor of using the fiid API.  The changes made to the
template seem to have been done so that the fiid API could be avoided??

3) The above changes break code.  Personally, this breaks my entire host
monitoring library here at LLNL.  On top of that, it would be difficult
for my host monitoring library to use the new sensor API, b/c my host
monitoring library is very simple.  All it does is return "ok" or "not
ok" for discrete sensors.  The list of strings returned is useless in my
library.

I think we should try to draw a line between the "pure" libfreeipmi API
and "tool helper functions".  It seems that the above changes have been
made as a convenience for the sensor-api library, which seems to be
almost exclusively for the sensors tool.  I think we should try and
avoid that.  If the sensor-API would like to do things differently than
the "pure" API, a different template should be created.  It should not
modify the existing API that is "correct" based on the IPMI specification.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory