From a37815575716751d9db1818573657019a0574188 Mon Sep 17 00:00:00 2001 From: Quentin Young Date: Wed, 14 Mar 2018 14:56:03 -0400 Subject: [PATCH] doc: cleanup some misc files * Translate plaintext stub documenting bgpd preprocessor constants for attributes into a RST file and include it in the doctree * Remove the Markdown version of the OSPF-API document, as I've already translated it into RST * Remove the Markdown version of the modules document, as I've already translated it into RST * Rename the various "Building_FRR_*" documents to match standard RST file conventions Signed-off-by: Quentin Young --- doc/developer/BGP-TypeCode | 24 -- doc/developer/OSPF-API.md | 263 ------------------ doc/developer/bgp-typecodes.rst | 28 ++ doc/developer/bgpd.rst | 1 + ..._Alpine.rst => building-frr-on-alpine.rst} | 0 ...entOS6.rst => building-frr-on-centos6.rst} | 0 ...entOS7.rst => building-frr-on-centos7.rst} | 0 ...ebian8.rst => building-frr-on-debian8.rst} | 0 ...ebian9.rst => building-frr-on-debian9.rst} | 0 ...ora24.rst => building-frr-on-fedora24.rst} | 0 ...SD10.rst => building-frr-on-freebsd10.rst} | 0 ...SD11.rst => building-frr-on-freebsd11.rst} | 0 ...eBSD9.rst => building-frr-on-freebsd9.rst} | 0 ...T.rst => building-frr-on-lede-openwrt.rst} | 0 ...etBSD6.rst => building-frr-on-netbsd6.rst} | 0 ...etBSD7.rst => building-frr-on-netbsd7.rst} | 0 ..._OmniOS.rst => building-frr-on-omnios.rst} | 0 ...nBSD6.rst => building-frr-on-openbsd6.rst} | 0 ...204.rst => building-frr-on-ubuntu1204.rst} | 0 ...404.rst => building-frr-on-ubuntu1404.rst} | 0 ...604.rst => building-frr-on-ubuntu1604.rst} | 0 doc/developer/building.rst | 34 +-- doc/developer/dev-modules.md | 119 -------- 23 files changed, 46 insertions(+), 423 deletions(-) delete mode 100644 doc/developer/BGP-TypeCode delete mode 100644 doc/developer/OSPF-API.md create mode 100644 doc/developer/bgp-typecodes.rst rename doc/developer/{Building_FRR_on_Alpine.rst => building-frr-on-alpine.rst} (100%) rename doc/developer/{Building_FRR_on_CentOS6.rst => building-frr-on-centos6.rst} (100%) rename doc/developer/{Building_FRR_on_CentOS7.rst => building-frr-on-centos7.rst} (100%) rename doc/developer/{Building_FRR_on_Debian8.rst => building-frr-on-debian8.rst} (100%) rename doc/developer/{Building_FRR_on_Debian9.rst => building-frr-on-debian9.rst} (100%) rename doc/developer/{Building_FRR_on_Fedora24.rst => building-frr-on-fedora24.rst} (100%) rename doc/developer/{Building_FRR_on_FreeBSD10.rst => building-frr-on-freebsd10.rst} (100%) rename doc/developer/{Building_FRR_on_FreeBSD11.rst => building-frr-on-freebsd11.rst} (100%) rename doc/developer/{Building_FRR_on_FreeBSD9.rst => building-frr-on-freebsd9.rst} (100%) rename doc/developer/{Building_FRR_on_LEDE-OpenWRT.rst => building-frr-on-lede-openwrt.rst} (100%) rename doc/developer/{Building_FRR_on_NetBSD6.rst => building-frr-on-netbsd6.rst} (100%) rename doc/developer/{Building_FRR_on_NetBSD7.rst => building-frr-on-netbsd7.rst} (100%) rename doc/developer/{Building_FRR_on_OmniOS.rst => building-frr-on-omnios.rst} (100%) rename doc/developer/{Building_FRR_on_OpenBSD6.rst => building-frr-on-openbsd6.rst} (100%) rename doc/developer/{Building_FRR_on_Ubuntu1204.rst => building-frr-on-ubuntu1204.rst} (100%) rename doc/developer/{Building_FRR_on_Ubuntu1404.rst => building-frr-on-ubuntu1404.rst} (100%) rename doc/developer/{Building_FRR_on_Ubuntu1604.rst => building-frr-on-ubuntu1604.rst} (100%) delete mode 100644 doc/developer/dev-modules.md diff --git a/doc/developer/BGP-TypeCode b/doc/developer/BGP-TypeCode deleted file mode 100644 index b3218079cc..0000000000 --- a/doc/developer/BGP-TypeCode +++ /dev/null @@ -1,24 +0,0 @@ - - BGP-4[+] UPDATE Attribute TypeCode list - - Value Attribute References -========================================================================= - 1 ORIGIN [RFC 4271] - 2 AS_PATH [RFC 4271] - 3 NEXT_HOP [RFC 4271] - 4 MULTI_EXIT_DISC [RFC 4271] - 5 LOCAL_PREF [RFC 4271] - 6 ATOMIC_AGGREGATE [RFC 4271] - 7 AGGREGATOR [RFC 4271] - 8 COMMUNITIES [RFC 1997] - 9 ORIGINATOR_ID [RFC 4456] - 10 CLUSTER_LIST [RFC 4456] - 11 DPA [draft-ietf-idr-bgp-dpa-05.txt(expired)] - 12 ADVERTISER [RFC 1863] - 13 RCID_PATH [RFC 1863] - 14 MP_REACH_NLRI [RFC 4760] - 15 MP_UNREACH_NLRI [RFC 4760] - 16 EXT_COMMUNITIES [RFC 4360] - 17 AS4_PATH [RFC 4893] - 18 AS4_AGGREGATOR [RFC 4893] -========================================================================= diff --git a/doc/developer/OSPF-API.md b/doc/developer/OSPF-API.md deleted file mode 100644 index 5774300c0b..0000000000 --- a/doc/developer/OSPF-API.md +++ /dev/null @@ -1,263 +0,0 @@ -# OSPF API Documentation - -[TOC] - -## Disclaimer - -The OSPF daemon contains an API for application access to the LSA database. This API was created by Ralph Keller, originally as patch for Zebra. Unfortunately, the page containing documentation of the API is no longer online. This page is an attempt to recreate documentation for the API (with lots of help of the WayBackMachine) - -## 1.  Introduction - -This page describes an API that allows external applications to access the link-state database (LSDB) of the OSPF daemon. The implementation is based on the OSPF code from FRRouting (forked from Quagga and formerly Zebra) routing protocol suite and is subject to the GNU General Public License. The OSPF API provides you with the following functionality: - -* Retrieval of the full or partial link-state database of the OSPF daemon. This allows applications to obtain an exact copy of the LSDB including router LSAs, network LSAs and so on. Whenever a new LSA arrives at the OSPF daemon, the API module immediately informs the application by sending a message. This way, the application is always synchronized with the LSDB of the OSPF daemon. -* Origination of own opaque LSAs (of type 9, 10, or 11) which are then distributed transparently to other routers within the flooding scope and received by other applications through the OSPF API. - -Opaque LSAs, which are described in RFC 2370 , allow you to distribute application-specific information within a network using the OSPF protocol. The information contained in opaque LSAs is transparent for the routing process but it can be processed by other modules such as traffic engineering (e.g., MPLS-TE). - -## 2.  Architecture - -The following picture depicts the architecture of the Quagga/Zebra protocol suite. The OSPF daemon is extended with opaque LSA capabilities and an API for external applications. The OSPF core module executes the OSPF protocol by discovering neighbors and exchanging neighbor state. The opaque module, implemented by Masahiko Endo, provides functions to exchange opaque LSAs between routers. Opaque LSAs can be generated by several modules such as the MPLS-TE module or the API server module. These modules then invoke the opaque module to flood their data to neighbors within the flooding scope. - -The client, which is an application potentially running on a different node than the OSPF daemon, links against the OSPF API client library. This client library establishes a socket connection with the API server module of the OSPF daemon and uses this connection to retrieve LSAs and originate opaque LSAs. - -![image](ospf_api_architecture.png) - -The OSPF API server module works like any other internal opaque module (such as the MPLS-TE module), but listens to connections from external applications that want to communicate with the OSPF daemon. The API server module can handle multiple clients concurrently. - -One of the main objectives of the implementation is to make as little changes to the existing Zebra code as possible. - -## 3.  Installation & Configuration - -Download FRRouting and unpack - -Configure your frr version (note that --enable-opaque-lsa also enables the ospfapi server and ospfclient). - -``` -% update-autotools -% sh ./configure --enable-opaque-lsa -% make - -``` - -This should also compile the client library and sample application in ospfclient. - -Make sure that you have enabled opaque LSAs in your configuration. Add the ospf opaque-lsa statement to your ospfd.conf: - -``` -! -*- ospf -*- -! -! OSPFd sample configuration file -! -! -hostname xxxxx -password xxxxx - -router ospf - router-id 10.0.0.1 - network 10.0.0.1/24 area 1 - neighbor 10.0.0.2 - network 10.0.1.2/24 area 1 - neighbor 10.0.1.1 - ospf opaque-lsa <============ add this statement! - -``` - -## 4. Usage - -In the following we describe how you can use the sample application to originate opaque LSAs. The sample application first registers with the OSPF daemon the opaque type it wants to inject and then waits until the OSPF daemon is ready to accept opaque LSAs of that type. Then the client application originates an opaque LSA, waits 10 seconds and then updates the opaque LSA with new opaque data. After another 20 seconds, the client application deletes the opaque LSA from the LSDB. If the clients terminates unexpectedly, the OSPF API module will remove all the opaque LSAs that the application registered. Since the opaque LSAs are flooded to other routers, we will see the opaque LSAs in all routers according to the flooding scope of the opaque LSA. - -We have a very simple demo setup, just two routers connected with an ATM point-to-point link. Start the modified OSPF daemons on two adjacent routers. First run on msr2: - -``` - > msr2:/home/keller/ospfapi/zebra/ospfd# ./ospfd -f /usr/local/etc/ospfd.conf -``` - -And on the neighboring router msr3: - - -``` - > msr3:/home/keller/ospfapi/zebra/ospfd# ./ospfd -f /usr/local/etc/ospfd.conf -``` - -Now the two routers form adjacency and start exchanging their databases. Looking at the OSPF daemon of msr2 (or msr3), you see this: - -``` - ospfd> show ip ospf database - - OSPF Router with ID (10.0.0.1) - - Router Link States (Area 0.0.0.1) - - Link ID ADV Router Age Seq# CkSum Link count - 10.0.0.1 10.0.0.1 55 0x80000003 0xc62f 2 - 10.0.0.2 10.0.0.2 55 0x80000003 0xe3e4 3 - - Net Link States (Area 0.0.0.1) - - Link ID ADV Router Age Seq# CkSum - 10.0.0.2 10.0.0.2 60 0x80000001 0x5fcb - -``` - -Now we start the sample main application that originates an opaque LSA. - - -``` - > cd ospfapi/apiclient - > ./main msr2 10 250 20 0.0.0.0 0.0.0.1 - -``` - -This originates an opaque LSA of type 10 (area local), with opaque type 250 (experimental), opaque id of 20 (chosen arbitrarily), interface address 0.0.0.0 (which is used only for opaque LSAs type 9), and area 0.0.0.1 - -Again looking at the OSPF database you see: - -``` - ospfd> show ip ospf database - - OSPF Router with ID (10.0.0.1) - - Router Link States (Area 0.0.0.1) - - Link ID ADV Router Age Seq# CkSum Link count - 10.0.0.1 10.0.0.1 437 0x80000003 0xc62f 2 - 10.0.0.2 10.0.0.2 437 0x80000003 0xe3e4 3 - - Net Link States (Area 0.0.0.1) - - Link ID ADV Router Age Seq# CkSum - 10.0.0.2 10.0.0.2 442 0x80000001 0x5fcb - - Area-Local Opaque-LSA (Area 0.0.0.1) - - Opaque-Type/Id ADV Router Age Seq# CkSum - 250.0.0.20 10.0.0.1 0 0x80000001 0x58a6 <=== opaque LSA - -``` - -You can take a closer look at this opaque LSA: - -``` - ospfd> show ip ospf database opaque-area - - OSPF Router with ID (10.0.0.1) - - - Area-Local Opaque-LSA (Area 0.0.0.1) - - LS age: 4 - Options: 66 - LS Type: Area-Local Opaque-LSA - Link State ID: 250.0.0.20 (Area-Local Opaque-Type/ID) - Advertising Router: 10.0.0.1 - LS Seq Number: 80000001 - Checksum: 0x58a6 - Length: 24 - Opaque-Type 250 (Private/Experimental) - Opaque-ID 0x14 - Opaque-Info: 4 octets of data - Added using OSPF API: 4 octets of opaque data - Opaque data: 1 0 0 0 <==== counter is 1 - -``` - -Note that the main application updates the opaque LSA after 10 seconds, then it looks as follows: - -``` - ospfd> show ip ospf database opaque-area - - OSPF Router with ID (10.0.0.1) - - - Area-Local Opaque-LSA (Area 0.0.0.1) - - LS age: 1 - Options: 66 - LS Type: Area-Local Opaque-LSA - Link State ID: 250.0.0.20 (Area-Local Opaque-Type/ID) - Advertising Router: 10.0.0.1 - LS Seq Number: 80000002 - Checksum: 0x59a3 - Length: 24 - Opaque-Type 250 (Private/Experimental) - Opaque-ID 0x14 - Opaque-Info: 4 octets of data - Added using OSPF API: 4 octets of opaque data - Opaque data: 2 0 0 0 <==== counter is now 2 - -``` - -Note that the payload of the opaque LSA has changed as you can see above. - -Then, again after another 20 seconds, the opaque LSA is flushed from the LSDB. - -#### Important note: - -In order to originate an opaque LSA, there must be at least one active opaque-capable neighbor. Thus, you cannot originate opaque LSAs of no neighbors are present. If you try to originate even so no neighbor is ready, you will receive a not ready error message. The reason for this restriction is that it might be possible that some routers have an identical opaque LSA from a previous origination in their LSDB that unfortunately could not be flushed due to a crash, and now if the router comes up again and starts originating a new opaque LSA, the new opaque LSA is considered older since it has a lower sequence number and is ignored by other routers (that consider the stalled opaque LSA as more recent). However, if the originating router first synchronizes the database before originating opaque LSAs, it will detect the older opaque LSA and can flush it first. - - -## 5.  Protocol and Message Formats - -If you are developing your own client application and you don't want to make use of the client library (due to the GNU license restriction or whatever reason), you can implement your own client-side message handling. The OSPF API uses two connections between the client and the OSPF API server: One connection is used for a synchronous request /reply protocol and another connection is used for asynchronous notifications (e.g., LSA update, neighbor status change). - -Each message begins with the following header: - -![image](ospf_api_msghdr.png) - -The message type field can take one of the following values: - -Messages to OSPF deamon | Value ------------------------ | ----- -MSG_REGISTER_OPAQUETYPE | 1 -MSG_UNREGISTER_OPAQUETYPE | 2 -MSG_REGISTER_EVENT | 3 -MSG_SYNC_LSDB | 4 -MSG_ORIGINATE_REQUEST | 5 -MSG_DELETE_REQUEST | 6 - -Messages from OSPF deamon | Value -------------------------- | ----- -MSG_REPLY | 10 -MSG_READY_NOTIFY | 11 -MSG_LSA_UPDATE_NOTIFY | 12 -MSG_LSA_DELETE_NOTIFY | 13 -MSG_NEW_IF | 14 -MSG_DEL_IF | 15 -MSG_ISM_CHANGE | 16 -MSG_NSM_CHANGE | 17 - -The synchronous requests and replies have the following message formats: - -![image](ospf_api_msgs1.png) - -The origin field allows to select according to the following types of origins: - -Origin | Value ------- | ----- -NON_SELF_ORIGINATED | 0 -SELF_ORIGINATED | 1 -ANY_ORIGIN | 2 - -The reply message has on of the following error codes: - -Error code | Value ----------- | ----- -API_OK | 0 -API_NOSUCHINTERFACE | -1 -API_NOSUCHAREA | -2 -API_NOSUCHLSA | -3 -API_ILLEGALSATYPE | -4 -API_ILLEGALOPAQUETYPE | -5 -API_OPAQUETYPEINUSE | -6 -API_NOMEMORY | -7 -API_ERROR | -99 -API_UNDEF | -100 - -The asynchronous notifications have the following message formats: - -![image](ospf_api_msgs2.png) - -## 6.  Original Acknowledgments from Ralph Keller - -I would like to thank Masahiko Endo, the author of the opaque LSA extension module, for his great support. His wonderful ASCII graphs explaining the internal workings of this code, and his invaluable input proved to be crucial in designing a useful API for accessing the link state database of the OSPF daemon. Once, he even decided to take the plane from Tokyo to Zurich so that we could actually meet and have face-to-face discussions, which was a lot of fun. Clearly, without Masahiko no API would ever be completed. I also would like to thank Daniel Bauer who wrote an opaque LSA implementation too and was willing to test the OSPF API code in one of his projects. diff --git a/doc/developer/bgp-typecodes.rst b/doc/developer/bgp-typecodes.rst new file mode 100644 index 0000000000..beb7ca1f8a --- /dev/null +++ b/doc/developer/bgp-typecodes.rst @@ -0,0 +1,28 @@ +BGP-4[+] UPDATE Attribute Preprocessor Constants +================================================ + +This is a list of preprocessor constants that map to BGP attributes defined by +various BGP RFCs. In the code these are defined as BGP_ATTR_. + ++-------+------------------+------------------------------------------+ +| Value | Attribute | References | ++=======+==================+==========================================+ +| 1 | ORIGIN | [RFC 4271] | +| 2 | AS_PATH | [RFC 4271] | +| 3 | NEXT_HOP | [RFC 4271] | +| 4 | MULTI_EXIT_DISC | [RFC 4271] | +| 5 | LOCAL_PREF | [RFC 4271] | +| 6 | ATOMIC_AGGREGATE | [RFC 4271] | +| 7 | AGGREGATOR | [RFC 4271] | +| 8 | COMMUNITIES | [RFC 1997] | +| 9 | ORIGINATOR_ID | [RFC 4456] | +| 10 | CLUSTER_LIST | [RFC 4456] | +| 11 | DPA | [draft-ietf-idr-bgp-dpa-05.txt(expired)] | +| 12 | ADVERTISER | [RFC 1863] | +| 13 | RCID_PATH | [RFC 1863] | +| 14 | MP_REACH_NLRI | [RFC 4760] | +| 15 | MP_UNREACH_NLRI | [RFC 4760] | +| 16 | EXT_COMMUNITIES | [RFC 4360] | +| 17 | AS4_PATH | [RFC 4893] | +| 18 | AS4_AGGREGATOR | [RFC 4893] | ++-------+------------------+------------------------------------------+ diff --git a/doc/developer/bgpd.rst b/doc/developer/bgpd.rst index 053c0779de..bda135c446 100644 --- a/doc/developer/bgpd.rst +++ b/doc/developer/bgpd.rst @@ -5,4 +5,5 @@ BGPD :maxdepth: 2 next-hop-tracking + bgp-typecodes diff --git a/doc/developer/Building_FRR_on_Alpine.rst b/doc/developer/building-frr-on-alpine.rst similarity index 100% rename from doc/developer/Building_FRR_on_Alpine.rst rename to doc/developer/building-frr-on-alpine.rst diff --git a/doc/developer/Building_FRR_on_CentOS6.rst b/doc/developer/building-frr-on-centos6.rst similarity index 100% rename from doc/developer/Building_FRR_on_CentOS6.rst rename to doc/developer/building-frr-on-centos6.rst diff --git a/doc/developer/Building_FRR_on_CentOS7.rst b/doc/developer/building-frr-on-centos7.rst similarity index 100% rename from doc/developer/Building_FRR_on_CentOS7.rst rename to doc/developer/building-frr-on-centos7.rst diff --git a/doc/developer/Building_FRR_on_Debian8.rst b/doc/developer/building-frr-on-debian8.rst similarity index 100% rename from doc/developer/Building_FRR_on_Debian8.rst rename to doc/developer/building-frr-on-debian8.rst diff --git a/doc/developer/Building_FRR_on_Debian9.rst b/doc/developer/building-frr-on-debian9.rst similarity index 100% rename from doc/developer/Building_FRR_on_Debian9.rst rename to doc/developer/building-frr-on-debian9.rst diff --git a/doc/developer/Building_FRR_on_Fedora24.rst b/doc/developer/building-frr-on-fedora24.rst similarity index 100% rename from doc/developer/Building_FRR_on_Fedora24.rst rename to doc/developer/building-frr-on-fedora24.rst diff --git a/doc/developer/Building_FRR_on_FreeBSD10.rst b/doc/developer/building-frr-on-freebsd10.rst similarity index 100% rename from doc/developer/Building_FRR_on_FreeBSD10.rst rename to doc/developer/building-frr-on-freebsd10.rst diff --git a/doc/developer/Building_FRR_on_FreeBSD11.rst b/doc/developer/building-frr-on-freebsd11.rst similarity index 100% rename from doc/developer/Building_FRR_on_FreeBSD11.rst rename to doc/developer/building-frr-on-freebsd11.rst diff --git a/doc/developer/Building_FRR_on_FreeBSD9.rst b/doc/developer/building-frr-on-freebsd9.rst similarity index 100% rename from doc/developer/Building_FRR_on_FreeBSD9.rst rename to doc/developer/building-frr-on-freebsd9.rst diff --git a/doc/developer/Building_FRR_on_LEDE-OpenWRT.rst b/doc/developer/building-frr-on-lede-openwrt.rst similarity index 100% rename from doc/developer/Building_FRR_on_LEDE-OpenWRT.rst rename to doc/developer/building-frr-on-lede-openwrt.rst diff --git a/doc/developer/Building_FRR_on_NetBSD6.rst b/doc/developer/building-frr-on-netbsd6.rst similarity index 100% rename from doc/developer/Building_FRR_on_NetBSD6.rst rename to doc/developer/building-frr-on-netbsd6.rst diff --git a/doc/developer/Building_FRR_on_NetBSD7.rst b/doc/developer/building-frr-on-netbsd7.rst similarity index 100% rename from doc/developer/Building_FRR_on_NetBSD7.rst rename to doc/developer/building-frr-on-netbsd7.rst diff --git a/doc/developer/Building_FRR_on_OmniOS.rst b/doc/developer/building-frr-on-omnios.rst similarity index 100% rename from doc/developer/Building_FRR_on_OmniOS.rst rename to doc/developer/building-frr-on-omnios.rst diff --git a/doc/developer/Building_FRR_on_OpenBSD6.rst b/doc/developer/building-frr-on-openbsd6.rst similarity index 100% rename from doc/developer/Building_FRR_on_OpenBSD6.rst rename to doc/developer/building-frr-on-openbsd6.rst diff --git a/doc/developer/Building_FRR_on_Ubuntu1204.rst b/doc/developer/building-frr-on-ubuntu1204.rst similarity index 100% rename from doc/developer/Building_FRR_on_Ubuntu1204.rst rename to doc/developer/building-frr-on-ubuntu1204.rst diff --git a/doc/developer/Building_FRR_on_Ubuntu1404.rst b/doc/developer/building-frr-on-ubuntu1404.rst similarity index 100% rename from doc/developer/Building_FRR_on_Ubuntu1404.rst rename to doc/developer/building-frr-on-ubuntu1404.rst diff --git a/doc/developer/Building_FRR_on_Ubuntu1604.rst b/doc/developer/building-frr-on-ubuntu1604.rst similarity index 100% rename from doc/developer/Building_FRR_on_Ubuntu1604.rst rename to doc/developer/building-frr-on-ubuntu1604.rst diff --git a/doc/developer/building.rst b/doc/developer/building.rst index e56744ad87..a10e4a245c 100644 --- a/doc/developer/building.rst +++ b/doc/developer/building.rst @@ -4,20 +4,20 @@ Building FRR .. toctree:: :maxdepth: 2 - Building_FRR_on_LEDE-OpenWRT - Building_FRR_on_Alpine - Building_FRR_on_CentOS6 - Building_FRR_on_CentOS7 - Building_FRR_on_Debian8 - Building_FRR_on_Debian9 - Building_FRR_on_Fedora24 - Building_FRR_on_FreeBSD10 - Building_FRR_on_FreeBSD11 - Building_FRR_on_FreeBSD9 - Building_FRR_on_NetBSD6 - Building_FRR_on_NetBSD7 - Building_FRR_on_OmniOS - Building_FRR_on_OpenBSD6 - Building_FRR_on_Ubuntu1204 - Building_FRR_on_Ubuntu1404 - Building_FRR_on_Ubuntu1604 + building-frr-on-lede-openwrt + building-frr-on-alpine + building-frr-on-centos6 + building-frr-on-centos7 + building-frr-on-debian8 + building-frr-on-debian9 + building-frr-on-fedora24 + building-frr-on-freebsd10 + building-frr-on-freebsd11 + building-frr-on-freebsd9 + building-frr-on-netbsd6 + building-frr-on-netbsd7 + building-frr-on-omnios + building-frr-on-openbsd6 + building-frr-on-ubuntu1204 + building-frr-on-ubuntu1404 + building-frr-on-ubuntu1604 diff --git a/doc/developer/dev-modules.md b/doc/developer/dev-modules.md deleted file mode 100644 index 87bc963188..0000000000 --- a/doc/developer/dev-modules.md +++ /dev/null @@ -1,119 +0,0 @@ -# Module and Hook support (developer docs) - -## What it does - -It uses `dlopen()` to load DSOs at startup. - - -## Limitations - -* can't load, unload, or reload during runtime. This just needs some work - and can probably be done in the future. -* doesn't fix any of the "things need to be changed in the code in the library" - issues. Most prominently, you can't add a CLI node because CLI nodes are - listed in the library... -* if your module crashes, the daemon crashes. Should be obvious. -* **does not provide a stable API or ABI**. Your module must match a version - of FRR and you may have to update it frequently to match changes. -* **does not create a license boundary**. Your module will need to link - libzebra and include header files from the daemons, meaning it will be - GPL-encumbered. - - -## Installation - -Look for `moduledir` in `configure.ac`, default is normally -`/usr/lib64/frr/modules` but depends on `--libdir` / `--prefix`. - -The daemon's name is prepended when looking for a module, e.g. "snmp" tries -to find "zebra_snmp" first when used in zebra. This is just to make it nicer -for the user, with the snmp module having the same name everywhere. - -Modules can be packaged separately from FRR. The SNMP and FPM modules are -good candidates for this because they have dependencies (net-snmp / protobuf) -that are not FRR dependencies. However, any distro packages should have an -"exact-match" dependency onto the FRR package. Using a module from a -different FRR version will probably blow up nicely. - -For snapcraft (and during development), modules can be loaded with full path -(e.g. -M `$SNAP/lib/frr/modules/zebra_snmp.so`). Note that libtool puts output -files in the .libs directory, so during development you have to use -`./zebra -M .libs/zebra_snmp.so`. - - -## Creating a module - -... best to look at the existing SNMP or FPM modules. - -Basic boilerplate: - -``` -#include "hook.h" -#include "module.h" - -static int -module_init (void) -{ - hook_register(frr_late_init, module_late_init); - return 0; -} - -FRR_MODULE_SETUP( - .name = "my module", - .version = "0.0", - .description = "my module", - .init = module_init, -) -``` - -The `frr_late_init` hook will be called after the daemon has finished its -other startup and is about to enter the main event loop; this is the best -place for most initialisation. - - -## Compiler & Linker magic - -There's a `THIS_MODULE` (like in the Linux kernel), which uses `visibility` -attributes to restrict it to the current module. If you get a linker error -with `_frrmod_this_module`, there is some linker SNAFU. This shouldn't be -possible, though one way to get it would be to not include libzebra (which -provides a fallback definition for the symbol). - -libzebra and the daemons each have their own `THIS_MODULE`, as do all loadable -modules. In any other libraries (e.g. `libfrrsnmp`), `THIS_MODULE` will use -the definition in libzebra; same applies if the main executable doesn't use -`FRR_DAEMON_INFO` (e.g. all testcases). - -The deciding factor here is "what dynamic linker unit are you using the symbol -from." If you're in a library function and want to know who called you, you -can't use `THIS_MODULE` (because that'll just tell you you're in the library). -Put a macro around your function that adds `THIS_MODULE` in the *caller's -code calling your function*. - -The idea is to use this in the future for module unloading. Hooks already -remember which module they were installed by, as groundwork for a function -that removes all of a module's installed hooks. - -There's also the `frr_module` symbol in modules, pretty much a standard entry -point for loadable modules. - - -## Hooks - -Hooks are just points in the code where you can register your callback to -be called. The parameter list is specific to the hook point. Since there is -no stable API, the hook code has some extra type safety checks making sure -you get a compiler warning when the hook parameter list doesn't match your -callback. Don't ignore these warnings. - - -## Relation to MTYPE macros - -The MTYPE macros, while primarily designed to decouple MTYPEs from the library -and beautify the code, also work very nicely with loadable modules -- both -constructors and destructors are executed when loading/unloading modules. - -This means there is absolutely no change required to MTYPEs, you can just use -them in a module and they will even clean up themselves when we implement -module unloading and an unload happens. In fact, it's impossible to create -a bug where unloading fails to de-register a MTYPE. -- 2.39.5