Hi Corey,
Could you please if my understanding
regarding sensor event handlers is ok or not?
To a sensor event handler we are getting
inputs as enum ipmi_event_dir_e dir, enum ipmi_thresh_e threshold, enum
ipmi_event_value_dir_e high_low.
So now if it is temperature sensor and it
detects a raise in temperature more than the given threshold value, then the
sensor event handler function will be called with the below values:
threashold
is upper eg. IPMI_UPPER_CRITICAL,
dir = IPMI_ASSERTION
high_low = IPMI_GOING_HIGH
and
if the temperature returns to normal then again the same function is called with
below values:
threashold
is upper eg. IPMI_UPPER_CRITICAL,
dir = IPMI_DEASSERTION
high_low = IPMI_GOING_HIGH
similarly for a voltage sensor and it
detect a drop in voltage than given threshold value then the function will be
called with below values:
threashold
is lower eg. IPMI_LOWER_CRITICAL,
dir = IPMI_ASSERTION
high_low = IPMI_GOING_LOW
and if the voltage again returns to normal
range then the function is called with below values:
threashold
is lower eg. IPMI_LOWER_CRITICAL,
dir = IPMI_DEASSERTION
high_low = IPMI_GOING_LOW
Please correct me if my understanding is
incorrect.
Thanks and regards
S Sarath
On Wednesday, May 7, 2014 11:23 AM, sarath azad <[email protected]> wrote:
Hi Corey,
Thanks for the information.
For this problem of reading sensor's reading, we are thinking to use
semaphores, on which our function which gets the sensor's reading, will be
waiting for. And the call back function which actually gets called when the
sensor reading is available/read, will signal the semaphore before leaving. Now
once the data is available, our function which was waiting on the semaphore
will have the sensor reading (obtained from call back data passed to call back
function), and resume and continue.
Also one more thing i have observed, (may be helpful to others) that suppose we
are running the "operation loop" as separate thread, then the call back
functions are getting run as part of (in context of ) that thread.
So using semaphores for synchronizing call back function with the main code
flow is possible (as both runs on separate threads).
Thanks and regards
S Sarath
On Thursday, May 1, 2014 4:53 AM, Corey Minyard <[email protected]> wrote:
On 04/30/2014 12:15 PM, sarath azad wrote:
> Hi Corey,
>
> Suppose we have a sensor's ID, then is there a way such that we can
> call a function which will
return its reading?
> Currently what I could see is that we can only
> call ipmi_sensor_pointer_cb() to call a callback function with
> pointer to the sensor
> inside this call back call ipmi_sensor_get_reading() passing
> another call back function
> now in this final call back function the sensor reading is
> available and we fill it in call back data (void *cb_data)
> So now through void *cb_data we can get the sensor reading. But the
> initial call to get the sensor reading, is not waiting for sensor
> reading value and simply continues after
> calling ipmi_sensor_pointer_cb().
What you state is correct.
>
> Could you please tell if there is any other way to get the sensor
> readings like calling a function which could fetch or wait till sensor
> reading is available and return the value ?
>
> What is the general way to get the sensor readings using OpenIPMI library?
OpenIPMI is completely non-blocking. This means that every single
function will run without doing anything that will block waiting for
something. Thus the callbacks for when things complete. You could
build a blocking framework on top of OpenIPMI, but nobody has done it at
this point.
I know it's inconvenient for what you want, but OpenIPMI was designed to
scale to monitor thousands of IPMI systems continuously. You just can't
do that with blocking calls. And the event-driven structure works very
nicely with GUIs.
-corey
>
> thanks and regards
> S Sarath
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
