Hey Matt, I noticed one or two minor nits, but I can fix em. I guess I am only perplexed by this design choice. It seems you want to have two threads. One thread does normal IPMI regularly, and the other thread will wait for the SMS_ATN bit. It appears that _ipmi_kcs_get_status() is the only place that the SMS_ATN bit is checked, so you need to be doing some type of other KCS in order to ever check for it?
Perhaps it'd be better to just have a function that regularly polls the SMS_ATN bit, and if it is true, return to the user?? Perhaps something like: poll_sms_atn(unsigned int poll_interval, unsigned int max_iterations) { while (count <= max_iterations) { lock_kcs_semaphore(); if (sms_atn bit set) break; unlock_kcs_sempahore(); sleep (poll_interval); } unlock_kcs_sempahore(); } ???? Al On Tue, 2010-02-23 at 08:27 -0800, Matt Jerdonek wrote: > > > Please give the attached patch a look. Since you two didn't like the > idea of a callback, I created an API to wait for an event and a second > API to cancel the wait. Basically the application will be responsible > for creating a thread which invokes the API. The API will block the > application's thread until an event occurs. The application will be > responsible for issuing a GET MESSAGE FLAGS command once the thread > unblocks. > > I had to use a semaphore to block the thread, so I made some small > changes to ipmi-semaphores.c as well. > > Note: this compiles, but I didn't try to run it yet. My customer has > not yet sent me the hardware with the KCS interface, so I don't have > hardware to exercise the code. > > Thanks again for your consideration, > -Matt > > -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list Freeipmi-devel@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-devel