Managing and Developing Dynamically Loadable Kernel Modules 489
Manufacturing Part Number: June 7, 2001 © Copyright 2001 © Hewlett-Packard Company. All rights reserved..
Managing and Developing Dynamically Loadable Kernel Modules 12 Managing and Developing Dynamically Loadable Kernel Modules Chapter 12 491
Managing and Developing Dynamically Loadable Kernel Modules Introduction Introduction The DLKM (Dynamically Loadable Kernel Module) feature provides the means to add a kernel module to a running UNIX system without rebooting the system or rebuilding the kernel. It also makes it possible to dynamically remove a kernel module from the UNIX system when the module is no longer needed, thereby freeing system resources for other use.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules This section describes the configuration and management of DLKMs. It focuses on loadable device drivers, because they constitute the majority of supported module types for HP-UX release 11.0 and later releases. It covers the following three topics: DLKM Concepts Introduces DLKM, defines important terms, and explains detailed technical concepts.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules What is DLKM The Dynamically Loadable Kernel Modules Infrastructure is an HP-UX operating system feature that allows “DLKM-Enabled” kernel modules to be dynamically loaded into, or unloaded from, the HP-UX kernel without having to re-link the entire kernel or reboot the system.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-1 Important Terms and Concepts Term / Concept Definition Traditional Module A Traditional Module is a kernel module whose configuration data has not been modularized and which can only be statically linked to the kernel.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-1 Important Terms and Concepts Term / Concept Definition Static Modularly Packaged Module A Static Modularly Packaged Module is a modularly packaged module that can only be linked statically to the kernel. Loadable Module A Loadable Module (or DLKM Module) is a modularly packaged module with the capability to be dynamically loaded into a running kernel.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-1 Important Terms and Concepts Term / Concept Definition Statically Configured Loadable Module A Statically Configured Loadable Module is a DLKM module that has the capability to be dynamically loaded but instead is configured to be statically built into the kernel.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-1 Important Terms and Concepts Term / Concept Definition Module Wrapper The additional code and data structures added to a kernel module which enable the DLKM infrastructure to logically connect and disconnect a loadable module to and from the running kernel. Boot Time Loading The loading of a dynamically loadable kernel module during the early phases of the system boot up process.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-1 Important Terms and Concepts Term / Concept Definition Planned Loading Phase, Configured Loading Phase The Planned Loading Phase and the Configured Loading Phase are configurable attributes that allow the administrator to request a specific load time for a DLKM module, as long as the loading phase is supported by the module.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules • its own master and system files • its own mod.o object file that implements only that module ❏ The mod.o object file must contain the module wrapper code. NOTE See the master (4) manual page for descriptions of the traditional and modular master files, and the system (4) manual page for a description of the traditional and modular system files.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules modules to be configured into the kernel while the system is running ❏ Conserving system resources by permitting the unloading of infrequently used modules when not in use ❏ Providing administrators with the ability to demand load and unload modules ❏ Providing the kernel with the ability to automatically load modules DLKM Loading Concepts When a module is dynamically loaded, its object file is read from
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules ❏ Autoload Event An autoload occurs when the kernel detects that a specific module is required to provide the functionality necessary to perform a task. The load is triggered by the initiation of the task. Once the required module is loaded, the task continues.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules DLKM Tools There are a number of HP-UX commands for installing, configuring, and managing DLKM modules, collectively known as the Kernel Configuration Tool Set. They are identified and briefly described in Table 12-1. For complete descriptions of these commands and their options, refer to the appropriate manpages.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-2 Kernel Configuration Tool Set Tool/ Command Action kmadmin (1M) Provides a general administrative interface to manage the DLKM modules registered with the currently running kernel. • -b option - sets the configured loading phase of the currently registered DLKM module • -k option – prints a list of all statically linked modules in the running kernel.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-2 Kernel Configuration Tool Set Tool/ Command Action kmmodreg (1M) Unregisters and re-registers loadable kernel modules with the running kernel. (Note: The interface for the initial module registration of a newly configured loadable module is kmupdate(1M), which in turn calls kmmodreg(1M).) • -U option - unregisters the specified loadable image.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-2 Kernel Configuration Tool Set Tool/ Command Action kmsystem (1M) Provides an interface to set and get a module’s planned configuration attributes prior to kernel or module configuration. Values and attributes displayed and set with kmsystem will be used to build a new kernel or module. • -b value option - sets the planned loading phase of the specified module.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Table 12-2 Kernel Configuration Tool Set Tool/ Command Action kmtune (1M) Provides an interface to set the tunable parameters • -l option – prints the values of all system parameters. • -q option – queries the value of the specified system parameter. • -r option – resets the value of the specified parameter to its default value in preparation for the next kernel or module configuration.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules are installed on the system. Furthermore, the format of such information is subject to change. Using the kmsystem(1M) and kmtune(1M) commands to modify the planned configuration prior to a whole kernel configuration or a module configuration will avoid corruption of the configuration files, and will ensure that the correct files are updated.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Use this chart as a reference to view all of the procedures and to determine the correct sequence in which to perform them. 2. DLKM Procedures This section presents step-by-step instructions for preparing, configuring, loading and unloading (or activating) loadable modules. The detailed procedures are presented in two sections: a. Dynamically Configured Loadable Module Procedures b.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Figure 12-1 DLKM Procedural Flowchart Start Dynamically Configuring a Loadable Module Dynamically or Statically Configured? Prepare module as Statically Configured Loadable Module using the command: kmsystem -c y -l n Prepare module as Dynamically Configured Loadable Module using the command: kmsystem -c y -l y OPTIONAL: Set planned loading phase using command: kmsystem -b Statically Configuring a
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules NOTE On Itanium-based systems, if the module you are configuring is required during the boot sequence, the module must either ❏ support the Boot Time Loading (BTL) and be configured to load at BOOT1 or BOOT2, or ❏ be statically configured .
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules the next kernel or module build. If value is y, it will be dynamically loadable. If value is n it will be statically linked. The -b value option specifies the phase during which the module will be loaded, assuming it has been configured and registered with the kernel.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules parameters used by the DLKM module or the static kernel. kmtune reads the master configuration files, the system description files, and the HPUX system file. For any modularly packaged module, kmtune writes user modified system parameters to the module’s system description file. Step 1.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules 5. Generates several C output files (including a makefile named config.mod) describing the system configuration 6. Generates the module’s registration information in KRS format. 7. Executes the makefile to configure the dynamically loadable module 8. Places the generated dynamically loadable module image files under the kernel function set directory associated with the running kernel.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules immediate update will also load the new module. Step 2. To update the image of a dynamically configured loadable module at system shutdown (an asynchronous update), execute the following kmupdate command: /usr/sbin/kmupdate -M module_name -a If you do not specify the -i or -a option, kmupdate will attempt to update the specified loadable module immediately.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules functions accessed through the module’s wrapper code To load a dynamically configured loadable module into the running kernel, execute the following kmadmin command: /usr/sbin/kmadmin -L module_name When the loading completes, an identifier (ID) number prints on the standard output to identify the module that was loaded.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Step 2. To unload a dynamically configured loadable module by ID number, execute this kmadmin command: /usr/sbin/kmadmin -u module_id Determining Which Modules are Currently Registered and/or Loaded Use the -S or -s option of the kmadmin command to view detailed information about all currently registered DLKM modules. Step 1.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules ❏ Module’s version string (loadable modules are given default version 0.1.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Preparing a Loadable Module for Static Linking You can use the kmsystem command to prepare a DLKM module for configuration as statically configured. Use the kmsystem command to set the planned configuration of a module.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules /usr/sbin/kmtune -r system_parameter_name At this point you have set the values of system parameters that will take effect after the next whole HP-UX kernel configuration, update and system reboot (see procedures below).
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Whole HP-UX Kernel Configuration to Include a Statically Configured Loadable Module When configuring a DLKM module into the system as statically configured, config builds an entire kernel, that is, configures the static kernel and all kernel modules. For a whole kernel configuration, config proceeds as follows: 1. Reads the traditional and modular master configuration files for the kernel modules 2.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules boot a newly configured kernel. WARNING Manually copying or moving kernel files is not a supported practice, and may result in corrupting the running kernel or other kernels on the system. See kmupdate(1M) for the supported interfaces to update and remove kernels.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules Call kmupdate after first calling config. If you include the -u option in the config invocation, there is no need to invoke kmupdate. The config -u command automatically invokes kmupdate.
Managing and Developing Dynamically Loadable Kernel Modules Managing Dynamically Loadable Kernel Modules To load the new kernel, move to the / directory, and execute the following shutdown command: cd / /usr/sbin/shutdown -r 524 Chapter 12
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules This section explains the process of writing modules in the DLKM format and provides background information specific to device driver development. It focuses on the writing and installation of loadable device drivers because they constitute the majority of supported DLKM modules for HP-UX 11.0 and later releases.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules file and other configuration files needed to install the module into the system. ❏ “Initializing and Terminating DLKM Modules” on page 538 describes the steps that each type of DLKM module must take to initialize and terminate itself.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules loaded in a certain phase of the booting process. The supported loading phase for a module is specified in the module’s master file. A module can have more than two supported loading phases defined concurrently. If no phases are specified in the master file, the module is loaded during runtime. The configured loading phase specifies the phase in which the module needs to be loaded.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Module dependency If a module requires another module in order to work properly, you can specify a dependency between them. The module loader attempts to load all the dependent modules when it finds dependencies during loading of a module. This module dependency mechanism is also applicable to Boot Time Loading.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules A module having BOOT2 as its configured loading phase will be loaded just after the statically linked device drivers have been initialized. Any modules either referenced by an auto-loading stub linked into the static kernel, or depended-upon by other modules loaded during the boot process, are loaded when they are referenced at boot time.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules ❏ The source code for a DLKM module contains two additional sections of code, one for the module’s wrapper and one for the module’s _load() and _unload() functions (routines). Module Wrapper The source code for a DLKM module must contain a wrapper, defined by the modwrapper structure, specifying the _load() and _unload() function entry points and other data structures used by the module.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules struct mod_type_data { char *mtd_info; void *mtd_pdata; }; struct modwrapper { int mw_rev; int (*mw_load)(); int (*mw_unload)(); void (*mw_halt)(); void *mw_conf_data; struct modlink *mw_modlink; }; The elements of the modwrapper structure are: ❏ mw_rev – module revision number; use MODREV in your module wrapper ❏ mw_load – pointer to module's _load() function ❏ mw_unload – pointer to module's _unload
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Table 12-3 Module Operations DLKM Module Type gio_mod_ops WSIO class driver gio_mod_ops WSIO interface driver str_drv_ops STREAMS driver str_mod_ops STREAMS module mod_misc_ops Miscellaneous module ❏ ml_type_data – pointer to a mod_type_data structure The elements of the mod_type_data structure are: ❏ mtd_info – information string returned to modstat() system call ❏ mtd_pdata – pointer to
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules struct modwrapper module_name_wrapper = { MODREV, module_name_load, module_name_unload, (void (*)())NULL, (void *)&module_name_conf_data, module_name_mod_link }; When a DLKM module is configured as statically linked, its wrapper is not used by the system.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules The _unload() function must clean up any resources that were allocated to the module, and it must remove all references to the module. Typical cleanup tasks include releasing private memory acquired by the module, removing device interrupts, disabling interrupts from the device, and canceling any outstanding timeout requests made by the module.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules or both of two keywords: stub which, by its presence, indicates that the module has stub. phases n where n is figured by computing the logical OR of the following mask value: 0x01 Phase 1 of the boot sequence 0x02 Phase2 of the boot sequence 0x04 Runtime The absence of this keyword indicates that the module supports only runtime loading (equivalent to phases 0x04).
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules system File Definition Every DLKM module requires a system file. The system file includes the following mandatory section keyword and four optional section keywords: ❏ $VERSION – (mandatory) indicates the version number for the file format. Version is defined as an integer and starts from one. Version 1 is the only supported file format for PA systems.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules whether, and/or when, to load the module upon a system reboot. It can be one of the following: A Auto 1 Phase 1 of the boot sequence 2 Phase 2 of the boot sequence I Init phase Absence of this section indicates that the module will be configured to be loaded only on demand or by the auto loading mechanism.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Modstub.o File Definition An optional component, the Modstub.o file is statically configured into the kernel as a “place holder” for functions implemented in a loadable module that will be loaded at a later time. Its purpose is to enable the kernel to resolve references to the absent module’s functions. Modstub.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules chain is only used during system boot, and there is no mechanism to remove the entry from the chain when the module is unloaded.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Therefore, the module's _load() function should perform both the installation tasks (those normally done during install for static modules) and the driver initialization tasks, and the dev_init chain should be ignored.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules NOTE The wsio_install_driver() function call returns 1 on success. However (and inconsistently), the wsio_uninstall_driver() function call returns 0 on success. Initialization for a statically linked WSIO class driver is unchanged from historical practice. That is, the initial driver entry point is module_name_install.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Example 12-5 WSIO Class Driver _init Function /* * Device initialization Link * Called only for statically linked drivers to link init * routine into list.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules if ( wsio_uninstall_driver(&module_name_wsio_info) ) { /* Uninstall failed! Return to a loaded, functional * state. */ printf(“module_name> wsio_uninstall_driver failed!!\n”); return (ENXIO); } /* Cancel pending timeouts, free allocated memory and * resources, etc.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules New support functions have been added to WSIO to allow interface drivers to add and remove their _attach() functions from the attach list. These functions are: int mod_wsio_attach_list_add(list_type, &attach_func); int mod_wsio_attach_list_remove(list_type, &attach_func); list_type specifies the attach list to use; valid entries are MOD_WSIO_CORE, MOD_WSIO_PCI, and MOD_WSIO_EISA.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Example 12-7 WSIO Interface Driver Loading and Initialization Coding static wsio_drv_info_t module_name_wsio_info = { ... }; static int (*module_name_saved_attach)(); int module_name_load(void *arg) { /* Use the drv_info passed to us instead of the static * version */ wsio_info.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules return (wsio_install_driver(&wsio_info); } /* Common attach function for both dynamic and * static modules */ int module_name_attach(int id, struct isc_table_type *isc) { /* Normal attach function operations */ ...
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Example 12-8 WSIO Interface Driver _unload Function int module_name_unload(void *arg) { int ret; struct isc_table_type *isc; void *token, *priv_ptr; return (EINVAL); /* Remove the attach function from the DLKM attach list. */ if (mod_wsio_attach_list_remove(MOD_WSIO_CORE, &module_name_core_attach)) { return(ENXIO); } /* Unregister the device probe.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules drivers must use the drv_info_t structure that is passed as an argument to the _load() function. The major numbers from this structure must also be used in the streams_info_t structure passed to str_install(). Sample _load() and _install() functions for a STREAMS driver are as follows: Example 12-9 STREAMS Driver _load and _install Functions static drv_info_t str_drv_info = { ...
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules STREAMS drivers, like WSIO class drivers, automatically track open() and close() system calls for the STREAMS device. The system will prevent a STREAMS driver from unloading whenever the device has one or more open file handles. Of course, the driver can still disallow an unload if this check is insufficient for its needs.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Example 12-11 STREAMS Module _load and _install Functions static streams_info_t str_info = { ...
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Miscellaneous Modules Miscellaneous modules can implement any feature within the kernel. As such, a miscellaneous module's _load() function must address all of the module's specific needs. Similarly, the module's _unload() function must determine for itself if it is safe to unload. The system will not allow a module to be unloaded if other loaded modules are dependent upon the module.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules aware that a subsequent kmupdate(1M) will again overwrite the vmunix.prev kernel. The recommended way to permanently save /stand/vmunix is to move it to a safe name, such as /stand/vmunix.bkup. Do Not Copy!: Copying the /stand/vmunix file may result in the eventual loss of the kernel component set necessary to boot the copy.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules +DA2.0W +DS2.0 -Ae -DLWSYSCALL -DPGPROF -DACLS -DAUDIT \ -DIDDS -D__ROSE__ -DHPONCPLUS -D__ROSEVILLE__ \ -DSPP_OBP_BOOT -DSPP_RUNWAY_ERR_ENABLED -DPARISC \ -DRDB -DNEW_RDB -DKGDB_ON -DIVT_INTERCEPT -DCOMB_FLIPPER \ -DNEW_MFCTL_W -DSTCP -DIPSEC -D_UNSUPPORTED \ -D_HPUX_SOURCE -D_XPG4_EXTENDED -D_KERNEL -D__STDC_EXT__ \ -D_CLEAN_BE -D__TEMP64__ -D__hp9000s800 -D__NO_EM_HDRS \ -U__hp9000s700 -o mod.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules NOTE The file locations receiving copies of the module’s component files may change in future HP-UX releases. Activating the DLKM After a module’s component files have been installed using the kminstall command, the module is ready to be configured and registered with the running kernel.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Also, set the following bit values in the flags field in the drv_info_t structure: if you have a block driver, set the DRV_BLOCK value; if you have a character driver set the DRV_CHAR value; if your driver is both a block and a character driver, set both values. Note that this step applies only to statically configured modules.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules NOTE You may be able to use the ioscan and insf commands to install special files in the /dev directory. If no options are specified, insf creates special files for all new devices in the system. New devices are those devices for which no special files have been previously created. See the ioscan (1M) and insf (1M) manual pages for more details.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules ❏ Corrupted interrupt stack ❏ Accessing critical data ❏ Overuse of local driver storage ❏ Incorrect DMA address mapping Updating the Module’s Components Use the -u option of the kminstall command to update a DLKM module’s components in the subdirectories of /usr/conf and /stand. Use this command when you modify one or more of the module’s component files.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules 2. Execute the following kminstall command: /usr/sbin/kminstall -u module_name kminstall copies the module’s component files to the appropriate locations, thereby overwriting the same named files at those locations. Removing the Module’s Components from the System Use the -d option of the kminstall command to remove a DLKM module’s components from the system.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules ❏ space.h – a configuration file that sets two flags and allocates space for the sample character driver ❏ Makefile – a makefile for the template character driver; initiates the compiling of dlclass.c and places a copy of mod.o in the current working directory ❏ mod.mk – a file called by Makefile that contains cc command and appropriate options to compile dlclass.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules 4. Execute the following command to generate the dlclass driver: make. The make (1) command examines the local Makefile and generates the dlclass driver according to the rules in the Makefile. It compiles dlclass.c into mod.o. It then installs and configures the driver.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Sample Component Files dlclass.c /* * Loadable/Unloadable Test Driver - dlclass */ #include #include #include #include #include #include #include #include
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules /* module type specific data */ static struct mod_type_data dlclass_drv_link = { "dlclass - Loadable/Unloadable Test Module", (void *)NULL }; static struct modlink dlclass_mod_link[] = { { &gio_mod_ops, (void *)&dlclass_drv_link }, { NULL, (void *)NULL } }; /* WSIO */ struct modwrapper dlclass_wrapper = { MODREV, dlclass_load, dlclass_unload, (void (*)())NULL, (void *)&dlclass_conf_data, dlclass_mod_
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules NULL, NULL, NULL, NULL, 0 /* /* /* /* reserved1 reserved2 reserved3 reserved4 /* d_flags */ */ */ */ */ }; static wsio_drv_data_t dlclass_wsio_data = { "pseudo_dlclass", /* drv_path */ T_DEVICE, /* drv_type */ DRV_CONVERGED, /* drv_flags */ NULL, /* drv_minor_build - field not used */ NULL, /* drv_minor_decode - field not used*/ }; static wsio_drv_info_t dlclass_wsio_info = { &dlclass_drv_info, &dl
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules return (0); } /* * UNLOAD */ static int dlclass_unload(void *drv_infop) { /* This function is only called when the administrator * attempts to unload the module and there are no open * devices using the module. If there is some reason that * the module should not be unloaded, check it now and * return non-zero.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules extern int (*dev_init)(void); /* Link my init function into chain */ dlclass_saved_init = dev_init; dev_init = (int (*)()) &dlclass_linked_init; /* Register driver with WSIO */ return ( wsio_install_driver(&dlclass_wsio_info) ); } /* * Device initialization Link * Called only for statically linked drivers to link init * routine into list.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules if (dlclass_debug) printf("dlclass> OPEN -- write buffer size = %d\n", dlclass_bufsz); return (0); } /* * CLOSE */ static int dlclass_close(dev_t dev, int flag, int mode) { if (dlclass_debug) printf("dlclass> CLOSE\n"); return (0); } /* * READ */ static int dlclass_read(dev_t dev, struct uio *uio) { if (dlclass_debug) printf("dlclass> READ\n"); if (uio->uio_offset == sizeof(dlclass_msg)) return (0); if
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules * WRITE */ static int dlclass_write(dev_t dev, struct uio *uio) { caddr_t bufp; char *end; int len, err; bufp = kmalloc(dlclass_bufsz+1, M_DYNAMIC, M_WAITOK); len = MIN(uio->uio_resid, dlclass_bufsz); /* print out user data */ if ( !(err = uiomove(bufp, len, UIO_WRITE, uio)) ) { bufp[len] = 0; printf("dlclass> ‘%s’", bufp); if (len == dlclass_bufsz) { printf(“...
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules base $$$ $DRIVER_DEPENDENCY $$$ $TYPE dlclass wsio_class $$$ $TUNABLE dlclass_no_unload dlclass_debug dlclass_bufsz $$$ pseudo cpmi -1 DLCLASS_NO_UNLOAD 0 DLCLASS_DEBUG DLCLASS_BUFSZ -1 1 40 8 system * * system file for "dlclass" module * $VERSION 1 $CONFIGURE Y $LOADABLE Y $TUNABLE $$$ space.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules Makefile # # This makefile needs to be invoked as follows: # #make # # Here, options include: # # all to configure module and create device file # config to configure the module in target system # dev to create the necessary device file # load to load the module # status to show status of loaded module(s) # clobber to unconfigure the module and remove device file # # CC must be set to the Ans
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules kmadmin -Q $(MODULE) | awk ‘/Character Major/ { \ rc=system(“mknod $(DEV_C) c “ $$3 “ 0”); \ exit rc; \ }’ mod.o:$(MODULE).c @if [ -n “$(ARCH)” ]; \ then \ make -f mod.mk mod.o ARCH=$(ARCH) MODULE=${MODULE}; \ elif [ “`uname -m`” = “ia64” ]; \ then \ make -f mod.mk mod.o ARCH=ia64 MODULE=${MODULE}; \ else \ make -f mod.mk mod.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules # #MODULE must be defined as the DLKM module to build #ARCH must be either ia64 or pa64 # INCDIR= -I.
Managing and Developing Dynamically Loadable Kernel Modules Developing Dynamically Loadable Kernel Modules all: mod.o mod.o: ${MODULE}.o ${LD} -r -o mod.o ${MODULE}.o ${MODULE}.o: ${MODULE}.c echo “Compiling ${MODULE}.c ...” ${CC} ${INCDIR} ${CC_OPTS_${ARCH}} ${IDENTS_${ARCH}} -o ${MODULE}.o -c ${MODULE}.
