Abstract:
A method, and a corresponding mechanism, are used for creating a self-describing kernel module. The method includes the steps of expressing data describing a module in a modmeta file format and creating a C language source file. The C language source file is created by translating the expressed data into a series of C language data structures, wherein the series of C language data structures comprises the C language source file. The C language source file is then compiled and linked into the module itself, thus making the module contain its own descriptive data.

Description:
TECHNICAL FIELD  
         [0001]    The technical field is processes and mechanisms used in configuring UNIX® operating systems. More particularly, the technical field relates to processes and mechanism for configuring kernel modules.  
         BACKGROUND  
         [0002]    One central component of a computer system operating in a UNIX® environment is an operating system kernel. In a typical UNIX® system, many applications, or processes may be running. All these processes use a memory-resident kernel to provide system services. The kernel manages the set of processes that are running on the system by ensuring that each such process is provided with some central processor unit (CPU) cycles when needed by the processes and by arranging for each such process to be resident in memory so that the process can run when required. The kernel provides a standard set of services that allows the processes to interact with the kernel and to simplify the task of the application writer. In the UNIX® environment, these services are sometimes referred to as “system calls,” because the process calls a routine in the kernel (system) to undertake some specific task. Code in the kernel will then perform the task for the process, and will return a result to the process. In essence, the kernel fills in the gaps between what the process intends to happen, and how the system hardware needs to be controlled to achieve the process&#39;s objective.  
           [0003]    The kernel&#39;s standard set of services is expressed as kernel modules (or simply, modules). The kernel typically includes modules such as drivers, including Streams drivers and device drivers, file system modules, scheduling classes, Streams modules, and system calls. These modules are compiled and subsequently linked together to form the kernel. Subsequently, when the system is started or “booted up”, the kernel is loaded into memory.  
           [0004]    Each module in the kernel has its own unique configuration. Some modules may include tunables, which govern the behavior of the kernel. Some tunables enable optional kernel behavior, and allow a system administrator to adapt a kernel to the administrator&#39;s own specific desires. In the discussion that follows, a master file means a file that gives configuration information for one or more kernel modules; a module means any separately configurable unit of kernel code; a system file means a file that contains administrator configuration choices; and module metadata means data that describes a module&#39;s capabilities and characteristics. In current UNIX® systems, module metadata are stored in master files. A system file is a flat text file that describes all of the configuration settings in a compact, machine-readable format.  
         SUMMARY  
         [0005]    What is disclosed is a method for creating a self-describing kernel module. The method includes the steps of expressing data describing a module in a modmeta file format and creating a C language source file. The C language source file is created by translating the expressed data into a series of C language data structures, where the series of C language data structures includes the C language source file. The C language source file is then compiled and linked into the module itself, thus making the module contain its own descriptive data.  
           [0006]    Also disclosed is a computer readable medium that includes routines that, when executed, performs the steps of expressing data describing a module in a modmeta file format and creating a C language source file. The C language source file is created by translating the expressed data into a series of C language data structures, where the series of C language data structures includes the C language source file. The C language source file is then compiled and linked into the module itself, thus making the module contain its own descriptive data.  
           [0007]    Further, what is disclosed is a mechanism for creating self-describing kernel modules. The mechanism includes a modineta compiler that translates the modmeta data file into a source code file. The source code file is a series of contiguous, variant length data structures.  
           [0008]    Finally, what is disclosed is a data structure for a kernel that includes self-describing kernel modules. The data structure includes a kernel executable, a kernel registry, and a self-describing kernel module. The self-describing kernel module includes kernel code and a modmeta table linked to the kernel code and contained within the self-describing kernel module. 
       
    
    
     DESCRIPTION OF THE DRAWINGS  
       [0009]    The detailed description will refer to the following figures in which like numerals refer to like items, and in which:  
         [0010]    [0010]FIG. 1 is a block diagram of an improved kernel structure that provides self-describing features;  
         [0011]    [0011]FIG. 2 is a block diagram of an embodiment of a mechanism that provides self-describing kernel modules;  
         [0012]    [0012]FIG. 3 illustrates a computer-readable medium that incorporates routines used to provide a self-describing kernel module; and  
         [0013]    [0013]FIG. 4 is a flow chart illustrating steps to establish a self-describing kernel module. 
     
    
     DETAILED DESCRIPTION  
       [0014]    In typical UNIX® systems, a kernel is initially built with a basic set of modules. The basic set of modules should comprise at least those modules needed to provide the standard set of services to applications. However, additional modules may be built into the kernel according to a system administrator&#39;s requirements and specifications. For example, an administrator may prefer to load certain device driver modules based on the frequency of usage of those modules.  
         [0015]    In a typical UNIX® system, the metadata describing each module are stored in data files, called master files in some prior art systems, which are stored separately from the modules they describe. The programs that build and maintain kernels read these files to gather necessary information about the modules.  
         [0016]    These features of current UNIX® systems impose some limitations on system reliability and flexibility. One such limitation is the possibility of outdated or missing master files. Because these prior art systems store these master files separately from the modules they describe, it is possible for the master files to be out of date with respect to changes made to the module. For example, a module could be replaced with a newer version, leaving its master file still describing the old version. It is also possible for the master files to be lost, as when a system administrator mistakenly removes the master file.  
         [0017]    Another limitation is the need to compile kernel code on a user&#39;s system. Such compiling begins with creating and compiling a conf.c file, which brings administrator-chosen tunable values into the kernel. Administrator chosen values are contained in system files. The conf.c file also brings descriptive information about the tunables, and device switch tables and similar tables into the kernel. The information needed for the tunables and the tables is contained in master and system files that exist outside the kernel space. Finally, the conf.c file contains lists of pointers to boot-time initialization routines for drive modules and other modules. A config routine generates these pointer lists using information in the master and system files. The config routine takes a file describing a system&#39;s tunable parameters and hardware support, and generates a collection of files that are then used to build a UNIX® kernel appropriate to a specific configuration. To avoid the need for compiling a conf.c file to accomplish the functions described above, requires giving the kernel code access to its own configuration data. More specifically, and as described in more detail below, each of the kernel&#39;s individual modules must have access to its own module metadata.  
         [0018]    In at least one current UNIX® environment, the operating system kernel is a collection of just under 300 modules. Each module contains executable code and data to provide some service in the kernel. Some modules are required by design of the operating system; others are chosen by are system administrator. Furthermore, a dependency may exist between or among some of the modules. For example if the system administrator chooses to include module A, the operating system will automatically include module B as well.  
         [0019]    Each module has an associated set of data that describes the module&#39;s capabilities and characteristics. These data have three audiences: the kernel itself needs the data to be able to use the module; kernel configuration (KC) tools that build the kernel need the data in order to resolve dependencies between modules; and the system administrator uses the data in order to decide which modules to choose.  
         [0020]    As noted above, in prior art systems these configuration data were stored in a set of configuration files that were separate and apart from the modules themselves. In an improvement over these prior art systems, these configuration data are no longer stored in a separate file or database. Instead, the configuration data are embedded in the module&#39;s code in such a way that both the kernel and the KC tools can read the configuration data. The system administrator can access the configuration data through the KC tools. This approach also removes the possibility that the configuration data can be outdated or missing.  
         [0021]    To implement the improved, self-describing kernel modules, a module developer expresses all of the data describing the module (referred to hereafter as “module metadata”) in a special file format, designated as a “modmeta file.” This file format is described in more detail later. In an embodiment, each such modmeta file is designated using a .modmeta suffix.  
         [0022]    The module developer then runs a “modmeta compiler” that translates the modmeta file format into a series of C language data structures to produce a C source file. The developer then combines the resulting C source file along with the rest of the module&#39;s code. The end result is that the module&#39;s metadata are embedded in the module that the metadata describe. For example, a module called stape would have created an stape.modmeta file, which would be stored along with the stape module&#39;s source code files. After the above build process was complete, the module developer would ship the resulting stape module to a system administrator as a single file containing an inseparable combination of the module&#39;s code and metadata.  
         [0023]    A module&#39;s modmeta file may specify the following types of information: module name; module version; module type; description; supported states; supported load times; dependencies on other modules; interfaces or symbols exported by the module; tunable parameters; and initialization functions. Device driver modules additionally will specify driver details, and file system modules will specify file system details. The modmeta file may specify other information in addition to that noted above.  
         [0024]    In creating these modmeta files, normal C data structures cannot be used because normal C data structures have embedded pointers, and pointers do not have usable values until the modules are linked into a complete kernel. The KC tools need to be able to extract the data before the kernel is completely configured. To overcome this limitation with C data structures, the herein described method and mechanism use contiguous, variant length data structures, i.e., very carefully tailored C data structures that do not have any embedded pointers.  
         [0025]    Normal C data structures also cannot be used because their use would require all modules to be recompiled whenever the structure definition changes. This is unacceptable in an environment where different modules are created by different authors in different companies at different times. To overcome this limitation with C data structures, the herein described method and mechanism use discriminated unions: i.e., the C data structures begin with special codes describing how the rest of the structures are interpreted.  
         [0026]    As noted above, the KC tools, in addition to the kernel itself, extract module metadata from the module. To facilitate this data extraction function, the C language data structures generated by the modmeta compiler are put into a special section of the module&#39;s object file. This special section contains only such data structures. Such data structures are put in this section using a special C compiler “pragma” that controls the section into which data structures are placed. Although module object files typically have all of their data in a single section, an industry-standard “ELF” file format for object files allows multiple data sections. The ELF file format is used by the method and mechanism for self describing kernel modules.  
         [0027]    Therefore, the KC tools can easily extract module metadata from a module object file, simply by looking for this special ELF format section in the file&#39;s index. When modules are linked together to form a complete kernel, the special ELF format sections used for each of the component modules&#39; metadata are combined into a single section—still separate from all other types of data—in the resulting kernel. This combination of section data is a feature of the linker, which is used by the method and mechanism for self describing kernel modules. Therefore, the KC tools can still easily extract module metadata from a complete kernel, again by looking for the special ELF format section in the kernel file&#39;s index. The kernel itself can find its modules&#39; metadata in the same way.  
         [0028]    Referring to FIG. 1, a kernel data space  100  is shown to include modules  101 , a kernel registry  105 , and a kernel executable  107 . The kernel registry  105  is a hierarchical database that is persistent across reboots. The kernel executable  107  includes config routines and other kernel code needed to support the modules  101 .  
         [0029]    In an embodiment, each of the modules  101  may exist in one of four administrator-specified states: unused, static, loaded, and auto. The unused state specifies that the module  101  is not in use. The static state corresponds to the traditional model of statically building a module into the kernel data space  100 . The loaded state and auto state each correspond to dynamically loading the module  101 . In the loaded state, the module  101  is forced to be loaded (e.g., loaded at boot). In the auto state, the module  101  is loaded in response to a system call.  
         [0030]    Following is an example of a modmeta file for a device driver named mydriver. The device driver, mydriver, supports all possible module states, can be loaded with other drivers during boot, or may be called subsequent to boot, has an initialization function to register itself with a driver infrastructure when in a static state, and is dependent on WSIO services in the kernel.  
                                                                                         module mydriver {                desc   “My Sample Driver”           type   wsio_intfc           version   1.0.0           states   auto loaded static           loadtimes   driver_install run           unloadable           dependency   wsio           initfunc   driver_install mydriver_install static           driver   {                type   char           class   lan           flags   save_conf           }                }                      
 
         [0031]    Each module  101  includes kernel code  102  and a modmeta table  103 . The code  102  executes a specific function for which the module  101  is designed. The modmeta table  103  describes the characteristics and capabilities of the module  101 . Metadata for a module  101  are used by kernel configuration tools when the module  101  is configured. The metadata are also used by various kernel services while the kernel module  101  is in use.  
         [0032]    As is apparent from the above description, the metadata for a kernel is comprised of the metadata for each of the kernel&#39;s component modules. In the context of metadata definitions, a module is any block of kernel code that should be treated independently during kernel configuration. Each kernel module  101  has its associated metadata stored in its own unique modmeta file. As will be described later, the modmeta file is compiled (producing the modmeta table  103 ) and linked into the kernel code  102  for the kernel module  101  that the modmeta file describes. This compiling and linking may be completed in a development environment when a modmeta compiler is not provided with a UNIX® distribution.  
         [0033]    [0033]FIG. 2 is a block diagram of a mechanism  110  for implementing self-describing kernel modules. The mechanism  110  includes a modmeta compiler  112  that receives modmeta source files and produces C language source files, which are then compiled with a standard C compiler to created modmeta object files, a linker  114  that receives the modmeta object files and kernel code object files, and links the two files to produce a module object file, and KC tools  116  that allows a system administrator to specify certain details of the self-describing kernel modules.  
         [0034]    [0034]FIG. 3 shows a computer system  120  using a UNIX® operating system. To implement self-describing kernel modules, a computer readable medium  130  is provided with appropriate programming, including the modmeta compiler  112 . The modmeta compiler, in combination with other tools, operates on the modmeta files for kernel modules to create the required self describing kernel modules. Alternatively, the computer readable medium  130  may include the kernel code  100  (see FIG. 1), which has been processed to invoke the self describing kernel module features, along with the KC tools  116  that the system administrator uses, for example, to select tunable values.  
         [0035]    The computer readable medium  130  may be any known medium, including optical discs, magnetic discs, hard discs, and other storage devices known to those of skill in the art. Alternatively, the programming required to implement the self describing kernel modules may be provided using a carrier wave over a communications network such as the Internet, for example.  
         [0036]    [0036]FIG. 4 is a flow chart illustrating a process  200  for implementing self describing kernel modules. The process begins when a modmeta file is created describing a module, block  205 . In block  210 , a modmeta compiler is used to compile the modmeta file. Compiling the modmeta file results in a file in C source code language that comprises contiguous, variant length data structures to represent the modmeta table, block  215 . Next, in block  220 , the C source code file is compiled, block  220 . Compiling the C source code file results in an object file that comprises data structures in a special ELF-format section, block  225 .  
         [0037]    Next, object file comprising the module&#39;s other code and data are retrieved, block  235 . In block  245 , the modmeta object file and the code object files are linked. As a result of linking, a single object file (block  250 ) is created, combining the contents of the modimeta object file and code object files. In block  255 , an administrator uses kernel configuration tools to specify tunable variables, and to make further changes to the module. The result of application of the kernel configuration tools is a complete kernel file having embedded metadata for all the kernel modules, block  260 .