[Openvpn-devel,v1] doc: Update doxygen references to removed tunnel_server_{udp, tcp}()
Commit Message
From: Razvan Cojocaru <razvanc@mailbox.org>
The point-to-multipoint server event loop is no longer split into
protocol-specific tunnel_server_udp() and tunnel_server_tcp()
functions; tunnel_server() now handles both UDP and TCP.
Update the Doxygen module documentation accordingly: list
tunnel_server() as the server-mode event loop implementation, and
rewrite the server-mode startup, initialization and cleanup sections
so that they describe tunnel_server() instead of the removed
functions.
Documentation only, no functional change.
Change-Id: I57b4122b292f643ddedd91e81bf95fe2f5b2e03a
Signed-off-by: Razvan Cojocaru <razvanc@mailbox.org>
Acked-by: Frank Lichtenheld <frank@lichtenheld.com>
Gerrit URL: https://gerrit.openvpn.net/c/openvpn/+/1850
---
This change was reviewed on Gerrit and approved by at least one
developer. I request to merge it to master.
Gerrit URL: https://gerrit.openvpn.net/c/openvpn/+/1850
This mail reflects revision 1 of this Change.
Acked-by according to Gerrit (reflected above):
Frank Lichtenheld <frank@lichtenheld.com>
@@ -60,6 +60,5 @@
* event loop function is called to drive the event processing. The
* following implementations are available:
* - Client mode using UDP or TCP: \c tunnel_point_to_point()
- * - Server mode using UDP: \c tunnel_server_udp()
- * - Server mode using TCP: \c tunnel_server_tcp()
+ * - Server mode using UDP or TCP: \c tunnel_server()
*/
@@ -117,10 +117,10 @@
* tunnel_point_to_point() or \c tunnel_server().
*
* In server-mode, \c main() calls the \c tunnel_server() function, which
- * transfers control to \c tunnel_server_udp() or \c
- * tunnel_server_tcp() depending on the external transport protocol.
+ * drives the event loop for both the UDP and TCP external transport
+ * protocols.
*
- * These functions receive the \c context created in \c main(). This
+ * This function receives the \c context created in \c main(). This
* object has a special status in server-mode, as it does not represent an
* active VPN tunnel, but does contain process-wide configuration
* parameters. In the source code, it is often stored in "top" variables.
@@ -130,11 +130,10 @@
* CM_CHILD_UDP or \c CM_CHILD_TCP, depending on the external transport
* protocol.
*
- * Both \c tunnel_server_udp_single_threaded() and \c tunnel_server_tcp()
- * perform similar initialization. In either case, a \c multi_context
- * structure is created, and it is initialized according to the
- * configuration stored in the top \c context by the \c multi_init() and
- * \c multi_top_init() functions.
+ * During initialization, \c tunnel_server() creates a \c multi_context
+ * structure, which is initialized according to the configuration stored
+ * in the top \c context by the \c multi_init() and \c multi_top_init()
+ * functions.
*
* @subsection tunnel_state_server_tunnels Creating and destroying VPN tunnels
*
@@ -146,8 +145,7 @@
*
* @subsection tunnel_state_server_cleanup Final cleanup
*
- * After the main event loop exits, both \c
- * tunnel_server_udp_single_threaded() and \c tunnel_server_tcp() perform
- * similar cleanup. They call \c multi_uninit() followed by \c
- * multi_top_free() to clean up the \c multi_context structure.
+ * After the main event loop exits, \c tunnel_server() performs the
+ * cleanup. It calls \c multi_uninit() followed by \c multi_top_free()
+ * to clean up the \c multi_context structure.
*/