[asterisk-commits] mmichelson: branch group/CCSS_Monitor_Restructure r242137 - /team/group/CCSS_...
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Thu Jan 21 17:57:57 CST 2010
Author: mmichelson
Date: Thu Jan 21 17:57:54 2010
New Revision: 242137
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=242137
Log:
Remove structures and functions no longer in use from ccss.h
Next step is to correct doxygen as well.
Modified:
team/group/CCSS_Monitor_Restructure/include/asterisk/ccss.h
Modified: team/group/CCSS_Monitor_Restructure/include/asterisk/ccss.h
URL: http://svnview.digium.com/svn/asterisk/team/group/CCSS_Monitor_Restructure/include/asterisk/ccss.h?view=diff&rev=242137&r1=242136&r2=242137
==============================================================================
--- team/group/CCSS_Monitor_Restructure/include/asterisk/ccss.h (original)
+++ team/group/CCSS_Monitor_Restructure/include/asterisk/ccss.h Thu Jan 21 17:57:54 2010
@@ -424,57 +424,6 @@
#define AST_CC_GENERIC_MONITOR_TYPE "generic"
/*!
- * \brief a link that connects two monitors in the weighted graph of
- * monitor structures.
- *
- * \details
- * The parent and child pointers are ao2 objects. This way, when a
- * monitor has no more links pointing to it, it will be automatically
- * destroyed.
- *
- * XXX I really think work should be done to make this structure not be
- * public. However, it is necessary given the way that the request_cc
- * monitor callback is currently handled.
- */
-struct ast_cc_monitor_link {
- /* The parent monitor (always an extension monitor) */
- struct ast_cc_monitor *parent;
- /* The child monitor (may be extension or device monitor) */
- struct ast_cc_monitor *child;
- /* Boolean indicator of whether the link is currently suspended */
- unsigned char is_suspended;
- /* Which instance of the core state machine does this link correspond
- * to
- */
- int core_id;
- /* Which service is being requested? */
- enum ast_cc_service_type service;
- /*!
- * \brief An ID for the available timer of a corresponding child device
- * monitor.
- *
- * \details
- * Really, it would seem a bit more logical to have this
- * ID reside on the monitor itself, but as far as ease-of-coding
- * is concerned, links already exist as something unique per
- * instance of a monitor. This way, multiple calls to a single
- * monitor may have independent available timers running.
- *
- * For links between two extension monitors, this field
- * never will be used.
- */
- int child_avail_id;
- /*!
- * Why are there two AST_LIST_ENTRY fields in this
- * struct? The reason is that each link is in a list
- * parent links of one monitor, and in a list of child
- * links for another.
- */
- AST_LIST_ENTRY(ast_cc_monitor_link) next_child;
- AST_LIST_ENTRY(ast_cc_monitor_link) next_parent;
-};
-
-/*!
* Used to determine which type
* of monitor an ast_cc_device_monitor
* is.
@@ -482,47 +431,10 @@
enum ast_cc_monitor_class {
AST_CC_DEVICE_MONITOR,
AST_CC_EXTENSION_MONITOR,
- /* A root monitor is a placeholder type, which serves
- * as a central root for a CCSS monitor tree. Its only job
- * is to pipe requests it receives from an extension monitor
- * to the core and vice-versa. Note that it is not mentioned
- * in CCSS_architecture.pdf because it is a fairly low-level
- * concept and doesn't bear mentioning there.
- */
- AST_CC_ROOT_MONITOR,
};
/* Forward declaration */
struct cc_monitor;
-/*!
- * \brief Structure that represents a CCSS monitor
- * \details
- * Both extension and device monitors will be represented
- * with this structure. Information specific to each monitor
- * type can be retrieved through the monitor_data union.
- */
-struct ast_cc_monitor {
- /*! The list of links to upstream extension monitors */
- AST_LIST_HEAD(,ast_cc_monitor_link) parent_links;
- AST_LIST_HEAD(,ast_cc_monitor_link) child_links;
- /*! Callback functions needed for specific monitor
- * implementations
- */
- const struct ast_cc_monitor_callbacks *callbacks;
- /*! Data specific to a monitor implementation */
- void *private_data;
- /* When a device monitor has a state change, it will
- * determine what link to send the change announcement
- * on, and then it will keep a pointer to that saved
- * link. This way, the monitor is sure to continue
- * communicating with the same upstream extension
- * monitor even if a lower-weighted link should
- * become unsuspended.
- */
- struct ast_cc_monitor_link *saved_link;
- struct ast_cc_interface *interface;
- int num_requests;
-};
struct ast_cc_monitor_callbacks {
/*!
@@ -532,20 +444,6 @@
* Examples include "generic" and "SIP"
*/
const char *type;
- /*!
- * \brief CC monitor initialization.
- *
- * \param monitor CC core monitor control.
- * \param core_id core_id of the CC transaction.
- *
- * \details
- * Implementers must allocate the monitor's private_data
- * and initialize it to whatever may be necessary.
- *
- * \retval 0 on success
- * \retval -1 on failure.
- */
- int (*init)(struct ast_cc_monitor *monitor, const int core_id);
/*!
* \brief Request CCSS.
*
@@ -564,7 +462,6 @@
* \retval 0 on success
* \retval -1 on failure.
*/
- int (*request_cc)(struct ast_cc_monitor *monitor, const int core_id, struct ast_cc_monitor_link *parent_link);
int (*request_cc2)(struct cc_monitor *monitor, int *available_timer_id);
/*!
* \brief Suspend monitoring.
@@ -579,7 +476,6 @@
* \retval 0 on success
* \retval -1 on failure.
*/
- int (*suspend)(struct ast_cc_monitor *monitor, const int core_id);
int (*suspend2)(struct cc_monitor *monitor);
/*!
* \brief Status response to an ast_cc_monitor_status_request().
@@ -597,7 +493,6 @@
* \retval 0 on success
* \retval -1 on failure.
*/
- int (*status_response)(struct ast_cc_monitor *monitor, const int core_id, enum ast_device_state devstate);
int (*status_response2)(struct cc_monitor *monitor, enum ast_device_state devstate);
/*!
* \brief Unsuspend monitoring.
@@ -611,7 +506,6 @@
* \retval 0 on success
* \retval -1 on failure.
*/
- int (*unsuspend)(struct ast_cc_monitor *monitor, const int core_id);
int (*unsuspend2)(struct cc_monitor *monitor);
/*!
* \brief Cancel the running available timer.
@@ -630,7 +524,6 @@
* \retval 0 on success
* \retval -1 on failure.
*/
- int (*cancel_available_timer)(struct ast_cc_monitor *monitor, const int core_id, int *sched_id);
int (*cancel_available_timer2)(struct cc_monitor *monitor, int *sched_id);
/*!
* \brief Destroy private data on the monitor.
@@ -642,22 +535,7 @@
* all heap-allocated data in the monitor's private_data pointer, including
* the private_data itself.
*/
- void (*destructor)(struct ast_cc_monitor *monitor);
void (*destructor2)(void *private_data);
- /*!
- * \brief Destroy private data for a specific monitor instance.
- *
- * \param core_id core_id of the CC transaction.
- *
- * \details
- * This callback is called when a specific call completion transaction
- * fails or completes. The main difference between this and the monitor destructor
- * is that this will be called for every CC call that occurs, whereas the destructor
- * function is only called when all activities on a monitor are completed. To drive
- * the point home, this destructor only has a core ID as a parameter. Use this to
- * locate the correct data to destroy.
- */
- void (*instance_destructor)(const int core_id);
};
/*!
@@ -1361,7 +1239,6 @@
* \retval 0 Request successfully queued
* \retval -1 Request could not be queued
*/
-int ast_cc_monitor_callee_available(struct ast_cc_monitor *monitor);
int ast_cc_monitor_callee_available2(struct cc_monitor *monitor);
/* END API FOR USE WITH/BY MONITORS */
More information about the asterisk-commits
mailing list