| The Linux network architecture is continually extended by new functions and protocol instances. In most cases, such an extension can even be dynamic (i.e., at runtime), as we saw in earlier chapters: network-layer protocols (Section 6.3), transport-layer protocols (Section 14.2.5), and packet filters (Section 19.3). All we need to implement such a dynamic extendibility are an appropriate interface and structures that manage the registered functionality. Functions like register_functionality() and unregister_functionality() can be used to register new functionalities with the kernel or remove existing functionalities. These registering and unregistering functions execute all initialization or cleanup steps required. For example, when removing a functionality, we have to ensure that it is no longer used in any other location of the kernel. This means that it has to use a reference counter (use counter) and check this counter (use_counter == 0?) before unregistering a functionality. The following operations are some of those normally executed in the registration function of an interface and undone, accordingly, in the unregistering functions: storing the new functionality of its management structure in a list, hash table, or another data structure; reserving memory for the required data structures or procuring other resources (IRQ, DMA, timer, etc.); incrementing reference counters; creating entries in the proc directory; using printk() to output status messages.
A new functionality (e.g., a new network-layer protocol or a new network device) normally takes many parameters. It would be difficult the pass all of these parameters individually in the registration function, mainly because they are required while the functionality is being used, which is normally outside the registration function. For this reason, a structure to manage the functionality is normally created. When registering a new functionality, this structure can be entered in a list, hash table, or similar management structures. This method ensures that we can access these functionalities and their parameters after the registration. Earlier chapters introduced a large number of such management structures, including the net_device structure for network devices and the packet_type structure for network-layer protocols. Such a management structure is filled with the parameters required before it is registered. Subsequently, a pointer to this management structure is passed to the registration function. The elements of these management structures assume two different tasks: Configuration data is set before a functionality is registered and passed as (configuration) parameter within the structure. In the packet_type structure (Chapter 6), for example, these parameters include the type and func variables. Runtime variables are not explicitly set before a functionality is registered. They are needed later when the functionality is used (e.g., next to link structures, or a use counter to count references).
After a registration, of course, we can also use configuration variables as runtime variables, if the initial value is no longer needed. After this brief overview of the principles of how to manage functionalities registered dynamically, the sections following discuss how the KIDS framework is implemented in the Linux kernel 2.4 (Linux KIDS). This framework relies heavily on the concept of dynamically extendable functionalities, as shown in our Linux KIDS example further below. Another interesting point is that the components and their instances are based on the object-oriented concept, and this approach could probably be adopted for other software projects in the Linux kernel. The next section begins with an introduction of its basics to better understand how the KIDS construction system works. |
