Some of the terminology used in EAP state machine is referring to EAPOL (IEEE 802.1X), but there is no strict requirement on the lower layer being IEEE 802.1X if EAP module is built for other programs than wpa_supplicant. These terms should be understood to refer to the lower layer as defined in RFC 4137.
New EAP methods need to be registered by adding them into the build (Makefile) and the EAP method registration list in the eap_peer_register_methods() function of eap_methods.c. Each EAP method should use a build-time configuration option, e.g., EAP_TLS, in order to make it possible to select which of the methods are included in the build.
EAP methods must implement the interface defined in eap_i.h. struct eap_method defines the needed function pointers that each EAP method must provide. In addition, the EAP type and name are registered using this structure. This interface is based on section 4.4 of RFC 4137.
It is recommended that the EAP methods would use generic helper functions, eap_msg_alloc() and eap_hdr_validate() when processing messages. This allows code sharing and can avoid missing some of the needed validation steps for received packets. In addition, these functions make it easier to change between expanded and legacy EAP header, if needed.
When adding an EAP method that uses a vendor specific EAP type (Expanded Type as defined in RFC 3748, Chapter 5.7), the new method must be registered by passing vendor id instead of EAP_VENDOR_IETF to eap_peer_method_alloc(). These methods must not try to emulate expanded types by registering a legacy EAP method for type 254. See eap_vendor_test.c for an example of an EAP method implementation that is implemented as an expanded type.