+ * except where otherwise noted.
+ *
+ *
+ * Data Structures
+ * ===============
+ *
+ * These functions work primarily with two different kinds of data structures:
+ *
+ * - "struct netdev", which represents a network device.
+ *
+ * - "struct netdev_rx", which represents a handle for capturing packets
+ * received on a network device
+ *
+ * Each of these data structures contains all of the implementation-independent
+ * generic state for the respective concept, called the "base" state. None of
+ * them contains any extra space for implementations to use. Instead, each
+ * implementation is expected to declare its own data structure that contains
+ * an instance of the generic data structure plus additional
+ * implementation-specific members, called the "derived" state. The
+ * implementation can use casts or (preferably) the CONTAINER_OF macro to
+ * obtain access to derived state given only a pointer to the embedded generic
+ * data structure.
+ *
+ *
+ * Life Cycle
+ * ==========
+ *
+ * Four stylized functions accompany each of these data structures:
+ *
+ * "alloc" "construct" "destruct" "dealloc"
+ * ------------ ---------------- --------------- --------------
+ * netdev ->alloc ->construct ->destruct ->dealloc
+ * netdev_rx ->rx_alloc ->rx_construct ->rx_destruct ->rx_dealloc
+ *
+ * Any instance of a given data structure goes through the following life
+ * cycle:
+ *
+ * 1. The client calls the "alloc" function to obtain raw memory. If "alloc"
+ * fails, skip all the other steps.
+ *
+ * 2. The client initializes all of the data structure's base state. If this
+ * fails, skip to step 7.
+ *
+ * 3. The client calls the "construct" function. The implementation
+ * initializes derived state. It may refer to the already-initialized
+ * base state. If "construct" fails, skip to step 6.
+ *
+ * 4. The data structure is now initialized and in use.
+ *
+ * 5. When the data structure is no longer needed, the client calls the
+ * "destruct" function. The implementation uninitializes derived state.
+ * The base state has not been uninitialized yet, so the implementation
+ * may still refer to it.
+ *
+ * 6. The client uninitializes all of the data structure's base state.
+ *
+ * 7. The client calls the "dealloc" to free the raw memory. The
+ * implementation must not refer to base or derived state in the data
+ * structure, because it has already been uninitialized.
+ *
+ * Each "alloc" function allocates and returns a new instance of the respective
+ * data structure. The "alloc" function is not given any information about the
+ * use of the new data structure, so it cannot perform much initialization.
+ * Its purpose is just to ensure that the new data structure has enough room
+ * for base and derived state. It may return a null pointer if memory is not
+ * available, in which case none of the other functions is called.
+ *
+ * Each "construct" function initializes derived state in its respective data
+ * structure. When "construct" is called, all of the base state has already
+ * been initialized, so the "construct" function may refer to it. The
+ * "construct" function is allowed to fail, in which case the client calls the
+ * "dealloc" function (but not the "destruct" function).
+ *
+ * Each "destruct" function uninitializes and frees derived state in its
+ * respective data structure. When "destruct" is called, the base state has
+ * not yet been uninitialized, so the "destruct" function may refer to it. The
+ * "destruct" function is not allowed to fail.
+ *
+ * Each "dealloc" function frees raw memory that was allocated by the the
+ * "alloc" function. The memory's base and derived members might not have ever
+ * been initialized (but if "construct" returned successfully, then it has been
+ * "destruct"ed already). The "dealloc" function is not allowed to fail. */