IBM Carrier Grade X3650 T User Manual page 91

Hide thumbs Also See for Carrier Grade X3650 T:
Table of Contents

Advertisement

IBM® Carrier Grade Server X3650 T
The flags argument shall be the bitwise OR of zero or more of the following three flags. These flags
(along with SYSCONLOG_NFY_DISABLED, (which may be returned by syscon_log_notify_get()) shall
be defined in <syscon.h>.
SYSCONLOG_ONCE_ONLY: If this flag is zero, the specified notification request shall remain in effect
until it is removed (via the syscon_log_notify_remove() function, or when the process execs or
terminates) or disabled. If this flag is set, the notification request shall be automatically disabled
(suppressing further notifications associated with that request) as soon as the first associated notification
is sent. Since a disabled request is of no further use, the application should remove it at some later time
to make room under the {SYSCONLOG_NOTIFY_MAX} limit (explained later in this section) for other
notification requests.
SYSCONLOG_SEND_RECID and SYSCONLOG_SEND_SIGVAL: These flags determine what value(s)
shall be made available to the function that handles delivery of an event notification. This function can be
either a signal-catching function (if the value of notification->sigev_notify is equal to SIGEV_SIGNAL) or
the start_routine of a new thread (if the value of notification->sigev_notify is equal to SIGEV_THREAD).
If SYSCONLOG_SEND_RECID is set, then the notification-handling function shall be able to obtain the
record ID of the event associated with the current notification:. A signal-catching function would call
syscon_log_siginfo_recid() to obtain this value, and a new thread's start_routine would call
syscon_log_sigval_recid().
If SYSCONLOG_SEND_SIGVAL is set, the value of notification->sigev_value (at least the sival_int or
sival_ptr member) shall be available to the notification-handling function. This value shall be available
either as the si_value member of the siginfo_t object that is passed to a signal-catching function, or as the
sigval object that is passed to a new thread's start_routine.
If neither SYSCONLOG_SEND_RECID nor SYSCONLOG_SEND_SIGVAL is set,
syscon_log_notify_add() shall behave as if SYSCONLOG_SEND_SIGVAL were set (and
SYSCONLOG_SEND_SIGVAL will be set in the flags returned by syscon_log_notify_get()). Whether
both these flags can be set is implementation-defined, and may depend on whether notification-
>sigev_notify is equal to SIGEV_SIGVAL or SIGEV_THREAD.
17.2.3.2.2
Delivery of Notification
If the value of notification->sigev_notify is equal to SIGEV_SIGNAL, the value of the si_code member of
the siginfo_t structure that is delivered to the signal-catching function shall be SI_EVLOG. The header
<syscon.h> shall define SI_EVLOG. It is not guaranteed that the value of SI_EVLOG shall be unique
among possible values for si_code. (For example, a switch statement that has cases for both SI_EVLOG
and SI_MESGQ might not compile.)
17.2.3.2.3
syscon_log_siginfo_recid()
The syscon_log_siginfo_recid() function shall store the record ID of the event record associated with the
current notification to the location pointed to by the recid argument. If the SYSCONLOG_SEND_RECID
flag is not set in the associated notification request, the value stored to recid shall be undefined.
This function is intended to be called from the signal-catching function that handles delivery of an event
notification. (In the associated notification request, notification->sigev_notify must be SIGEV_SIGNAL.)
The info and context arguments shall be equal to the info and context arguments of the signal-catching
function. The effect of calling syscon_log_siginfo_recid() under other circumstances shall be undefined.
Revision 3.0
83

Advertisement

Table of Contents
loading

Table of Contents