Hey A.B, > Al, Unfortunately SMS_ATN is KCS specific. So we can't create an > abstracted API.
There's no reason other drivers won't have "interrupt callbacks" in the future. We can abstract it by calling the API function something like "interrupt_callback". The only driver supported with it would be KCS in the beginning. Al On Sun, 2010-02-21 at 04:29 -0800, Anand Babu Periasamy wrote: > Matt Jerdonek wrote: > > Al & Anand, > > > > Thanks for the quick response. I'm planning on using libfreeipmi to > > create a custom application that, among other things, will have to read > > event flags from the local event log and query sensors on local and > > remote BMCs. > > > > I looked at the spec, and I think I have a slightly different > > understanding (I'm not saying I'm right -- I may be misunderstanding the > > spec). I don't think SMS_ATN and OBF can be used interchangeably. > > Here's my understanding: > > 1) If the SMS_ATN bit is set the local BMC requires some attention. > > 2) A GET MESSAGE FLAGS command should be sent to query the BMC. > > 3) If bit 0 is set in the response, that indicates a receive message is > > available. From looking at the ipmi_kcs_cmd_api_ipmb code, it appears > > as if that code polls the local BMC with GET MESSAGE cmds instead of > > using this bit to indicate when the response from the remote BMC is > > ready. While polling may not be ideal, it's certainly ok for my > > application. > > 4) If bit 1 is set in the response, that indicates an event is available. > > 5) I'll ignore the pre-watchdog timeout and OEM bits for now ... > > > > I don't understand how libfreeipmi notifies the application that an > > event is available without monitoring the SMS_ATN bit. I think I want > > to create a patch that does the following: > > 1) Creates a callback from libfreeapi to the application when an event > > occurs. > > 2) Monitors the SMS_ATN bit. > > 3) If set, invokes the callback. > > > > The application would be responsible for issuing the GET MESSAGE FLAGS > > command and handling the response. One downside of this approach is > > that it prevents you from ever making ipmi_kcs_cmd_api_ipmb > > event-driven. What do you two think? > > > > Thanks, > > -Matt > > ------------------------------------------------------------------------ > > *From:* Al Chu <[email protected]> > > *To:* Matt Jerdonek <[email protected]> > > *Cc:* [email protected] > > *Sent:* Thu, February 18, 2010 10:58:06 AM > > *Subject:* Re: [Freeipmi-devel] KCS Driver & SMS_ATN Register > > > > Hi Matt, > > > > Definitely open to patches. Looking over the IPMI spec, I agree w/ > > A.B., it seems to be more useful for a higher level monitoring, w/ the > > Get Message Flags and similar commands. I can think of several patch > > ideas: > > > > 1) add a KCS driver flag for checking for SMS_ATN in addition to OBF (or > > instead of??). Flags may be propogated up into higher level APIs too. > > > > 2) an additional function that checks for SMS_ATN in addition/or instead > > of OBF that users can call instead. > > > > It would be useful to understand your use case too. Are you using the > > KCS driver and IPMI bridging commands to bridge from one BMC to another > > BMC? > > > > Thanks, > > > > Al > > > > On Wed, 2010-02-17 at 18:51 -0800, Matt Jerdonek wrote: > > > Hello, > > > > > > The KCS driver appears to not use the SMS_ATN register. This register > > > is useful for BMC-to-BMC communication to know when the remote BMC has > > > responded. Are there any plans to monitor this register in future > > > releases? If not, are the maintainers open to including a patch? > > > > > > Thanks, > > > -Matt > > I have attached a patch to give you an idea. I did not even compile it yet. > If ipmi_kcs_read_sms_atn() returns 1, then you should call > ipmi_cmd_get_message_flags() > function and check what type of event occurred. > > nt ipmi_kcs_read_sms_atn (ipmi_kcs_ctx_t ctx); > int ipmi_cmd_get_message_flags (ipmi_ctx_t ctx, fiid_obj_t obj_cmd_rs); > Use this "tmpl_cmd_get_message_flags_rs" to parse the message contents. > > All IPMI commands have request (write) and response (read) transaction model. > So FreeIPMI > drivers doesn't have to wait for interrupts. All responses are triggered by > its own > requests. Driver internally uses OBF to poll for response immediately after > request > command. Polling is very short lived. > > OBF is appropriate only when you send a command request. For general polling > of hardware > triggered events, one should use SMS_ATN register. Instead of creating a > callback model, > it is better to expose ipmi_kcs_read_sms_atn () function directly. It works > like an > asynchronous function. Let the application retain the control and decide how > to thread or > poll using this function. > > Al, Unfortunately SMS_ATN is KCS specific. So we can't create an abstracted > API. > -- 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
