Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register

[Al Chu]

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
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory