Sending this to the list instead of just to Corey (forgot to reply-all).
Corey,
Thanks for the comments. I had been waffleing on the same issue i.e. make
it look like the message came from the ipmc receive message queue or from
the ipmc event queue..
I ended up going with the message queue because
a) Some of the status register bits that cause the OEM0 flag are events but
many are not. So what I am creating is not exclusively an event alert
message but a more generic request message to the payload to perform an
action (check status reg). Which seemed to fit better in the "it's a
command to the SMS from some other entity" / handle_ipmb_get_msg_cmd() path.
b) When a user space app registers to receive events - it gets all events
and all events go to all registered apps. I liked being able to narrow the
receiver list down by having an app that just registered for a particular
netfn / cmd.
The one fly in the ointment was the error response from the stack. I read
it that the stack response when there is no listener will be to send a
IPMI_INVALID_CMD_COMPLETION_CODE to the ipmc. From running it, it appears
that the ipmc just drops this message.
Given a & b and seeing that the error response caused no problems to the
ipmc I went with passing it up as a message. If you think that it truly
ought to be an event then I will be happy to go that way.
Thanks
David
On 4/17/07, Corey Minyard <[EMAIL PROTECTED]> wrote:
Sorry, I've been very slow replying to this.
> And I'll throw another thread into the queue here as well.
>
> The version of pigeonpoint I am working with does not implement an
> event queue. It uses the ATTN char and the OEM0 flag bit to indicate
> that there are bits of interest in the status register which can be
> retrieved with the oem command "get_status". Among these bits of
> interest are 'graceful reboot request', 'diag interrupt request',
> 'shutdown alert', 'reset alert', 'sensor alert', and various bus events.
>
> When the OEM0 bit in the flag msg is set I would like to kick off an
> OEM based request that sends a get_status command and then responds
> appropriately to the bits set in the response message.
>
> It seems like this would be best done in user space (or as much as
> possible). I noticed the 'oem_data_avail_handler' hook in the serial
> handle_flags routine. As well I was experimenting with registering
> for commands from user space. So I added an oem_data_handler to
> ipmi_serial.c that creates an alert message and passes it up the stack
> to ipmi_msghandler to give to anyone registerd for the specific oem
> netfn and command. In user space I have a daemon that registers for
> the oem netfn & cmd, waits for the alert message, does a oem
> get_status command to the ipmc, and then can take action when the
> get_status response comes back.
>
> I will put my patch for this in line below (not that large) for your
> review and comments. Is this a good / appropriate way to do this? Is
> there a better / more appropriate method?
Well, sort of. This should probably come up as an event, not an
incoming command, since if you are not listening the stack will issue an
error response. But other than that, this is ok, I think.
-corey
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Openipmi-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openipmi-developer
