From: Al Chu <address@hidden>
To: Matt Jerdonek <address@hidden>
Cc: Anand Babu Periasamy <address@hidden>; address@hidden
Sent: Wed, February 24, 2010 12:49:59 PM
Subject: Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register
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@hiddenComputer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory