Al, I'm not sure I understand your concern. Using either the blocking semaphore as I suggested, or the blocking polling as you suggested, the application will have to create at least 2 threads: one to wait for events, and another to do everything else. Right?
If that's the case, isn't using a semaphore a better approach in that it doesn't use as many processor cycles and alerts the application immediately? Thanks, -Matt ________________________________ From: Al Chu <[email protected]> To: Matt Jerdonek <[email protected]> Cc: Anand Babu Periasamy <[email protected]>; [email protected] 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 [email protected] Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory
_______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
