On 04/28/2014 02:57 AM, sarath azad wrote: > Hi Corey, > > Thanks for the immediate reply and valuable inputs. > > Could you please provide some more info regarding the 2nd option that > you mentioned: > “you can provide your own OS handler and use your own event loop.” > Does it means calling perform_one_op() in a loop in our code instead > of infinitely operating operation_loop() call? > Or does it mean to do the individual select calls as in the > operation_loop / perform_one_op functions in our code where we are > doing the monitoring. > If we want to periodically (every 3 seconds or so) look for sensor > events (threshold crossed events like temperature over given > operational range etc) on our system/domain: > Do we need to call perform_one_op() for one full scan, for events > (threshold crossed events) on our system/domain? > Do we need to call it some ‘x’ number of times for one full scan (not > the initial scan, as it confirmed by the “domain_fully_up” callback) > or is there any other callback for this? > Or Do we need to have individual select calls instead of > perform_one_op() calls?
I think you are misunderstanding how this works. The os handler is an interface that provides OS services for OpenIPMI. There are several available. If you are coding in C you are probably using the unix (posix) one. Unless you are using threads and then you need the pthread one. Part of the OS handler deals with files and I/O. The posix one for perform_one_op() keeps track of a set of files descriptors you have registered with it, and it calls select on those. Then, if something comes in, or a timer times out, it will call the handler for the file descriptor or timer. Then it returns. If you need something where you are waiting for something with select, you can register that fd with the OS handler and give it a function to call, and it will call your function when data comes in. The big problem is that openipmi must constantly be running. If you call select in your code and don't call perform_one_op(), then openipmi will be starved for time and not work. -corey > > My purpose is to > 1. get sensor readings when a request comes (on demand) > 2. periodically monitor the sensors for malfunction or threshold > crossed events and report > > For this which options is more suitable and efficient: > > option 1: > At startup register all the call backs to detect sensors > and threshold crossed events > Using domain_fully_up callback get all the sensor ids, > store in list and use to respond to sensor reading queries > In a separate thread run operational loop, for handling > the events. > > Option 2: > At startup register all the call backs to detect sensors and threshold > crossed events > Run perform_one_op() in a loop only till domain_fully_up. > So now we have all the sensors detected and maintain a list of it. > Now start a thread which sleeps and periodically wakes up > looking for events by, calling the perform_one_op() ‘x’ number of > times for one full scan or do individual select calls for one full scan. > > Thanks and regards > S Sarath > > Could you please provide some more info regarding the 2nd option that > you mentioned: > You can use OpenIPMI's event loop, or you can > provide your own OS handler and use your own event loop. > On Saturday, April 26, 2014 8:09 PM, Corey Minyard <[email protected]> > wrote: > On 04/26/2014 05:30 AM, sarath azad wrote: > > > > Could you please help regarding sensor's event handling using OpenIPMI > > library? > > > > I am writing an application to monitor the sensors on my machine > > (server) using OpenIPMI library. I have ran the sample programs > > provided with OpenIPMI library and below are my understanding from > > that, please correct me if I am wrong: > > > > 1. while opening the domain (ipmi_open_domain) we will provide > > all the call back functions to be called when a sensor is added or > > removed and also the event handlers which will be called when an event > > is detected on the sensor. > > Yes, that is correct. > > > 2. Now I am getting the sensors added only if I am running > > os_hnd->operation_loop(os_hnd); or os_hnd->perform_one_op(os_hnd, > > NULL) functions. > > Yes, the operation loop is what actually runs things in the library. > Sort of like X windows, if you are familiar with that. > > > > > Could you please tell : > > > > 1. For receiving the events on the sensors whether its threshold > > is crossed etc and getting the corresponding event handlers callback > > functions to be called, do we need to keep continuously run the > > functions operation_loop / perform_one_op? > > Yes, you should continuously call the operation loop. You have two > basic options here: > > 1. Run the event loop in a separate thread. OpenIPMI is thread-safe, > but you will have to deal with multithreading in your code. > 2. Run all of your operations from the event loop. I'm not sure how > your code is designed, but this is generally the easiest option. > > Basically, if your code is already multi-threaded, then option 1 is > probably the easiest. If your code is not multi-threaded, then you > probably have some event loop someplace where you call select() or > poll() and distribute out the events from there. Then option 2 is > probably the best. You can use OpenIPMI's event loop, or you can > provide your own OS handler and use your own event loop. > > > > > 2. What is the role of the scan interval provided by > > ipmi_domain_set_sel_rescan_time() and > > ipmi_domain_set_ipmb_rescan_time()? Does it impact operation_loop / > > perform_one_op? > > Those set the time between rescans of the event log and the IPMB bus. > The IPMB bus scan is probably not that critical, but some hardware can > hot add/remove management controllers. The event log is a bigger deal, > that sets the maximum amount of time between when an event occurs and > when the event is detected by the library. > > > Inside the operation_loop / perform_one_op functions we are doing > > select system call and waiting for some events to occur. How this is > > effected by ipmi_domain_set_sel_rescan_time() and > > ipmi_domain_set_ipmb_rescan_time()? > > > It will mess up timing. Why don't you use the os handler select call? > That way you don't have to do the select call, the OS handler will do it > for you and distribut out the events? > > -corey > > > > > Thanks and regards > > S Sarath > > > > > > > > > > > > ------------------------------------------------------------------------------ > > Start Your Social Network Today - Download eXo Platform > > Build your Enterprise Intranet with eXo Platform Software > > Java Based Open Source Intranet - Social, Extensible, Cloud Ready > > Get Started Now And Turn Your Intranet Into A Collaboration Platform > > http://p.sf.net/sfu/ExoPlatform > > > > > > _______________________________________________ > > Openipmi-developer mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/openipmi-developer > > > > ------------------------------------------------------------------------------ "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
