[asterisk-commits] mmichelson: branch group/CCSS r215685 - in /team/group/CCSS: include/asterisk...
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Wed Sep 2 17:05:03 CDT 2009
Author: mmichelson
Date: Wed Sep 2 17:04:59 2009
New Revision: 215685
URL: http://svn.asterisk.org/svn-view/asterisk?view=rev&rev=215685
Log:
Back to the "this code compiles" stage.
Modified:
team/group/CCSS/include/asterisk/ccss.h
team/group/CCSS/main/ccss.c
Modified: team/group/CCSS/include/asterisk/ccss.h
URL: http://svn.asterisk.org/svn-view/asterisk/team/group/CCSS/include/asterisk/ccss.h?view=diff&rev=215685&r1=215684&r2=215685
==============================================================================
--- team/group/CCSS/include/asterisk/ccss.h (original)
+++ team/group/CCSS/include/asterisk/ccss.h Wed Sep 2 17:04:59 2009
@@ -339,116 +339,6 @@
/* BEGIN TREE STRUCTURES AND APIS FOR APP_DIAL'S USE */
-/* The tree app_dial uses must be simple, goddammit. What is needed?
- * The name of the device/extension being dialed, and what ccss is
- * relevant for the specific device.
- *
- * Think about Dial's operation...When a device is called, it all
- * happens within the same thread. However, if Dial calls, say, two
- * Local channels, then there will be two simultaneous threads
- * which will try to manipulate the same structure. We need a lock.
- * Of course the other problem is that if this is going to exist
- * as a datastore on the channel, then dialing local channels should
- * probably result in their increasing a reference count on the data.
- *
- * Actually, there really doesn't need to be a new lock for this structure.
- * After all, since I'll be using a datastore, I'll need to lock the channel
- * to operate on the datastore.
- */
-
-/* So the gory datastore details will be in app_dial. However, the structure
- * it makes use of needs to be accessible to the CC core as well. So that
- * is why this is here and not in app_dial. All right.
- */
-
-/* All right, so while an actual tree-like structure is necessary in order
- * to handle all the intricacies of the weighted graph that a monitor uses,
- * for a simple phone call, that won't be necessary. All that's necessary
- * is a linked list of devices. Each device contains an indication of who
- * its "parent" is. This way, A tree may be easily constructed by traversing
- * the list. We can guarantee that we will generally be going in a top-to-bottom
- * order.
- */
-
-/* This may be a candidate for opacity. Who the heck knows. */
-struct ast_cc_interface {
- /* Every interface has an id associated with it. Think of
- * it like a "primary key"
- */
- unsigned int id;
- /* Who is this interface's parent interface? The "root" of
- * the tree will have 0 for this. Everyone else will have at
- * least 1 as their parent_id.
- */
- unsigned int parent_id;
- /* What service was offered by the endpoint. Note that
- * this field is completely irrelevant for ast_cc_interfaces
- * representing dialplan extensions.
- */
- enum ast_cc_service_type service_offered;
- /* What class of monitor is being offered here
- */
- enum ast_cc_monitor_class monitor_class;
- /*!
- * The type of monitor that should be used for this interface
- *
- * This will be something like "extension" "generic" or "SIP"
- * This should point to a static const char *, so there is
- * no reason to make a new copy.
- */
- const char *monitor_type;
- AST_LIST_ENTRY(ast_cc_interface) next;
- /* The name of the interface/extension. local channels will
- * have 'exten at context' for a name. Other channel types will
- * have 'tech/device' for a name.
- */
- char name[1];
-};
-
-/*!
- * \brief The "tree" of interfaces that is dialed.
- *
- * It is reference counted since several threads may need
- * to use it, and it may last beyond the lifetime of a single
- * thread.
- */
-AST_LIST_HEAD(ast_cc_interface_tree, ast_cc_interface);
-
-/*!
- * \brief Destructor function for an ast_cc_interface tree
- *
- * \param data The ast_cc_interface_tree whose refcount has reached 0
- */
-void ast_cc_interface_tree_destroy(void *cc_interface_tree);
-
-/* END TREE STRUCTURES AND API FOR APP_DIAL'S USE */
-
-
-/*!
- * \brief a link that connects two monitors in the weighted graph of
- * monitor structures.
- *
- * 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.
- */
-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;
- /* The weight associated with this link. Lower weights have higher
- * priority
- */
- unsigned long weight;
- /* 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
- */
- const unsigned int core_id;
-};
-
/*! Used to determine which type
* of monitor an ast_cc_device_monitor
* is.
@@ -468,6 +358,117 @@
AST_CC_ROOT_MONITOR,
};
+/* The tree app_dial uses must be simple, goddammit. What is needed?
+ * The name of the device/extension being dialed, and what ccss is
+ * relevant for the specific device.
+ *
+ * Think about Dial's operation...When a device is called, it all
+ * happens within the same thread. However, if Dial calls, say, two
+ * Local channels, then there will be two simultaneous threads
+ * which will try to manipulate the same structure. We need a lock.
+ * Of course the other problem is that if this is going to exist
+ * as a datastore on the channel, then dialing local channels should
+ * probably result in their increasing a reference count on the data.
+ *
+ * Actually, there really doesn't need to be a new lock for this structure.
+ * After all, since I'll be using a datastore, I'll need to lock the channel
+ * to operate on the datastore.
+ */
+
+/* So the gory datastore details will be in app_dial. However, the structure
+ * it makes use of needs to be accessible to the CC core as well. So that
+ * is why this is here and not in app_dial. All right.
+ */
+
+/* All right, so while an actual tree-like structure is necessary in order
+ * to handle all the intricacies of the weighted graph that a monitor uses,
+ * for a simple phone call, that won't be necessary. All that's necessary
+ * is a linked list of devices. Each device contains an indication of who
+ * its "parent" is. This way, A tree may be easily constructed by traversing
+ * the list. We can guarantee that we will generally be going in a top-to-bottom
+ * order.
+ */
+
+/* This may be a candidate for opacity. Who the heck knows. */
+struct ast_cc_interface {
+ /* Every interface has an id associated with it. Think of
+ * it like a "primary key"
+ */
+ unsigned int id;
+ /* Who is this interface's parent interface? The "root" of
+ * the tree will have 0 for this. Everyone else will have at
+ * least 1 as their parent_id.
+ */
+ unsigned int parent_id;
+ /* What service was offered by the endpoint. Note that
+ * this field is completely irrelevant for ast_cc_interfaces
+ * representing dialplan extensions.
+ */
+ enum ast_cc_service_type service_offered;
+ /* What class of monitor is being offered here
+ */
+ enum ast_cc_monitor_class monitor_class;
+ /*!
+ * The type of monitor that should be used for this interface
+ *
+ * This will be something like "extension" "generic" or "SIP"
+ * This should point to a static const char *, so there is
+ * no reason to make a new copy.
+ */
+ const char *monitor_type;
+ AST_LIST_ENTRY(ast_cc_interface) next;
+ /* The name of the interface/extension. local channels will
+ * have 'exten at context' for a name. Other channel types will
+ * have 'tech/device' for a name.
+ */
+ char name[1];
+};
+
+/*!
+ * \brief The "tree" of interfaces that is dialed.
+ *
+ * It is reference counted since several threads may need
+ * to use it, and it may last beyond the lifetime of a single
+ * thread.
+ */
+AST_LIST_HEAD(ast_cc_interface_tree, ast_cc_interface);
+
+/*!
+ * \brief Destructor function for an ast_cc_interface tree
+ *
+ * \param data The ast_cc_interface_tree whose refcount has reached 0
+ */
+void ast_cc_interface_tree_destroy(void *cc_interface_tree);
+
+/* END TREE STRUCTURES AND API FOR APP_DIAL'S USE */
+
+
+/*!
+ * \brief a link that connects two monitors in the weighted graph of
+ * monitor structures.
+ *
+ * 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.
+ */
+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;
+ /* The weight associated with this link. Lower weights have higher
+ * priority
+ */
+ unsigned long weight;
+ /* 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
+ */
+ const unsigned int core_id;
+ AST_LIST_ENTRY(ast_cc_monitor_link) next;
+};
+
/*!
* \brief Structure that represents a CCSS monitor
* Both extension and device monitors will be represented
@@ -477,6 +478,7 @@
struct ast_cc_monitor {
/*! One of CCBS or CCNR. */
enum ast_cc_monitor_class monitor_class;
+ const char *monitor_type;
/*! 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;
Modified: team/group/CCSS/main/ccss.c
URL: http://svn.asterisk.org/svn-view/asterisk/team/group/CCSS/main/ccss.c?view=diff&rev=215685&r1=215684&r2=215685
==============================================================================
--- team/group/CCSS/main/ccss.c (original)
+++ team/group/CCSS/main/ccss.c Wed Sep 2 17:04:59 2009
@@ -453,9 +453,9 @@
return 0;
}
-static int cc_monitor_hash_fn(void *obj, int flags)
-{
- struct ast_cc_monitor *monitor = obj;
+static int cc_monitor_hash_fn(const void *obj, int flags)
+{
+ const struct ast_cc_monitor *monitor = obj;
/* I have no idea if adding the two hashes together
* like this increases the odds of hash collisions or
* not.
@@ -824,20 +824,20 @@
strcpy(monitor->name, monitor_name);
monitor->callbacks = callbacks;
monitor->callbacks->init(monitor, core_id);
- AST_LIST_HEAD_INIT(monitor->child_links);
- AST_LIST_HEAD_INIT(monitor->parent_links);
+ AST_LIST_HEAD_INIT(&monitor->child_links);
+ AST_LIST_HEAD_INIT(&monitor->parent_links);
ao2_link(cc_monitors, monitor);
return monitor;
}
-static ast_cc_monitor *find_or_create_monitor(struct ast_cc_monitor *parent, struct ast_cc_interface *interface)
+static struct ast_cc_monitor *find_or_create_monitor(struct ast_cc_monitor *parent, struct ast_cc_interface *interface, const int core_id)
{
/* I'll leave the finding part for later. For now, I'll place the
* creation code here
*/
struct ast_cc_monitor *new_monitor;
struct ast_cc_monitor_link *new_link;
- struct ast_cc_monitor finder = alloca(sizeof(finder) + strlen(interface->name));
+ struct ast_cc_monitor *finder = alloca(sizeof(finder) + strlen(interface->name));
int monitor_created = 1;
strcpy(finder->name, interface->name);
@@ -857,12 +857,14 @@
return NULL;
}
- AST_LIST_HEAD_INIT(new_monitor->parent_links);
- AST_LIST_HEAD_INIT(new_monitor->child_links);
- new_link->child = ao2_ref(new_monitor);
- new_link->parent = ao2_ref(parent);
- AST_LIST_INSERT_TAIL(parent->child_links, new_link, next);
- AST_LIST_INSERT_TAIL(new_monitor->parent_links, new_link, next);
+ AST_LIST_HEAD_INIT(&new_monitor->parent_links);
+ AST_LIST_HEAD_INIT(&new_monitor->child_links);
+ new_link->child = new_monitor;
+ new_link->parent = parent;
+ ao2_ref(new_link->child, +1);
+ ao2_ref(new_link->parent, +1);
+ AST_LIST_INSERT_TAIL(&parent->child_links, new_link, next);
+ AST_LIST_INSERT_TAIL(&new_monitor->parent_links, new_link, next);
return new_monitor;
}
@@ -902,7 +904,7 @@
struct ast_cc_interface *child_interface_iterator;
ast_assert(strcmp(parent_interface_iterator->monitor_type, "extension") == 0);
- target = find_or_create_monitor(parent, parent_interface_iterator);
+ target = find_or_create_monitor(parent, parent_interface_iterator, core_instance->core_id);
/* XXX Do something here in case target is NULL */
parent = target;
AST_LIST_TRAVERSE_SAFE_BEGIN(pending_offer->called_tree, child_interface_iterator, next) {
@@ -910,7 +912,7 @@
if (child_interface_iterator->parent_id != parent_interface_iterator->id) {
continue;
}
- child = find_or_create_monitor(parent, child_interface_iterator);
+ child = find_or_create_monitor(parent, child_interface_iterator, core_instance->core_id);
if (strcmp(child_interface_iterator->monitor_type, "extension")) {
/* If we aren't dealing with an extension interface, then we
* can remove it from the list since we know it will have no
More information about the asterisk-commits
mailing list