Linux Kernel Extension Module Guidelines
The following sections outline various points to consider when a software product's compatibility with Novell OES is being assessed. These guidelines specifically address requirements that pertain to applications that are written as Linux Kernel Extensions.
For Novell OES Ready software products, it is assumed that all of these points have been considered.
Linux Kernel Extension Guideline #1
The product's kernel modules, and related source code, should be distributed under the GPL license and have been submitted to kernel.org. (If no, please consider: Appendix A).
Linux Kernel Extension Guideline #2
SuSE PLDP Compliant
The product's kernel modules participate in SuSE's Partner Linux Driver Program (PLDP) program.
NOTE: The Partner Linux Driver Process (PLDP) combines technology and processes to ensure, as much as possible, that customers can update to new kernels without adversely affecting the functioning of external kernel modules.
Linux Kernel Extension Guideline #3
Load Features Documented
Product kernel module component "load arguments" are documented in the product documentation.
Linux Kernel Extension Guideline #4
OES Kernel Module Conflicts
The product install does NOT cause the product conflict with OES kernel modules with regard to module names or system resources (such as port numbers, etc.)
Linux Kernel Extension Guideline #5
Forced Termination/Unload Handling
The product's kernel module components gracefully selfterminate when unloaded, appropriately saving product data and releasing dynamically allocated resources. The kernel module components also properly implement the "can_unload" functionality in the module descriptor to resist unloading when appropriate.
Linux Kernel Extension Guideline #6
Dynamic Resource Configuration and Management
For the product's kernel module components, I/O ports, Hardware Interrupt channels, DMA channels and Hardware Mapped Memory are configurable and manageable by the root user (when these system resources are referenced by the kernel module components).
Linux Kernel Extension Guideline #7
Proper Memory Access and Manipulation
Product kernel module components do not access or manipulate memory inappropriately. This includes the following:
- Product kernel module components do not directly modify native kernel machine code, or the machine code of any other loaded kernel module.
Linux Kernel Extension Guideline #8
Exported Interface Resilient
Interfaces exported by kernel module product components are resilient. This includes the following:
- Data pointers passed from userspace applications to product kernel module components are validated (by appropriate probing) by the kernel module. This requirement applies to IOCTL handlers.
- Driver IOCTL handlers return an error code of (1) for unknown IOCTL requests.
- Product does not add driver IOCTLs that duplicate existing ones.
Linux Kernel Extension Guideline #9
Correct Kernel Space Usage
Product kernel module components do not contain code that would be better implemented in user address space code.
Linux Kernel Extension Guideline #10
Maximum CPU Time Slice
Product kernel module components do not have nonpreemptive code paths that exceed an average CPU time slice of 40ms, and do not have nonpreemptive code paths that ever exceed a CPU time slice longer than 150ms.
Linux Kernel Extension Guideline #11
Functions exported by product kernel module components do not duplicate the functionality of native kernel functions.
Linux Kernel Extension Guideline #12
Product kernel module components do not implement privileged CPU instructions directly. Instead, the kernel module components implement standard Linux APIs for these instructions. For example:
- CPUID asm/processor.h
- RDMSR asm/msr.h
- WRMSR asm/msr.h
- RDTSC asm/msr.h
- RDPMC asm/msr.h
- INB asm/io.h
- OUTB asm/io.h
- TLB Flush asm/pgtable.h
Linux Kernel Extension Guideline #13
Console Message Flood Control
Product kernel modules report unusual/unexpected errors using the standard printk() kernel function only when necessary. Generated printk() messages are informative, avoid flooding the console with error messages when error conditions are detected (flood control), and associate a KERN_* message (as defined in /linux/include/linux/kernel.h).
NOTE: KERN_* messages include; KERN_EMERG, KERN_ALERT, KERN_CRIT, KERN_ERR, KERN_WARNING, KERN_NOTICE, KERN_INFO and KERN_DEBUG.
Linux Kernel Extension Guideline #14
Function Status Codes
Functions exported by product kernel modules always return a status value to caller requests. This includes returning a value of zero (0) to indicate that the function's task was performed successfully. Functions exported by product kernel modules do not return a value of (1) or (1) to indicate a generic failure. All standard errors returned from product kernel module functions use the standard errors provided by Linux kernel header files; including: linux/include/linux/errno.h, linux/include/asm/errno.h, linux/include/asmgeneric/errnobase.h and linux/ include/asmgeneric/errno.h.
Kernel module functions return negative values to indicate errors (ie: "return EIO", not "return EIO"). Functions exported by kernel modules that return pointer values properly implement the ERR_PTR(), PTR_ERR() and IS_ERR() kernel macros.
Linux Kernel Extension Guideline #15
Product kernel module components avoid calling panic() except in extreme unrecoverable situations where the kernel has become unstable. Device drivers do not call panic().
Linux Kernel Extension Guideline #16
Implementation of Sysfs (and the new driver model)
Product kernel modules (drivers) use sysfs when exporting information about devices to userspace, and also properly implement sysfs to adjust driver and device properties from user space.
Linux Kernel Extension Guideline #17
Initialization Status Reporting
When initializing, device drivers (and pseudo device drivers) issue (printk) messages to the system log indicating which device(s) were found that the driver can interface with.
Linux Kernel Extension Guideline #18
Product kernel module components do not disable interrupts unless required. When required, these components limit disabling interrupts to as short a time as possible (less than 10ms).
Linux Kernel Extension Guideline #19
Semaphores and Spinlocks
Product kernel module components use the standard Linux APIs provided in linux/samaphore.h and linux/spinlock.h when semaphores and locks are required, and do not implement proprietary (inline assembly) semaphores or spinlocks.
Linux Kernel Extension Guideline #20
Accessing PCI Memory
Product kernel module components that access PCI memory do so through the Linux PCI ABI, and do not access PCI memory directly.