Đang tải... (xem toàn văn)
Advanced Operating Systems - Lecture 38: Loadable kernel modules. This lecture will cover the following: loadable kernel modules and device drivers; linux module management; linux module conflict resolution; linux module registration; signals and asynchronous event notification;...
CS703 Advanced Operating Systems By Mr Farhan Zaidi Lecture No. 38 Overview of today’s lecture Loadable Kernel modules and device drivers Linux module management Linux module conflict resolution Linux module registration Signals and asynchronous event notification Loadable Kernel Modules (Linux & Solaris) Sections of kernel code that can be compiled, loaded, and unloaded independent of the rest of the kernel A kernel module may typically implement a device driver, a file system, or a networking protocol The module interface allows third parties to write and distribute, on their own terms, device drivers or file systems that could not be distributed under the GPL Kernel modules allow a Linux system to be set up with a standard, minimal kernel, without any extra device drivers built in Three components to Linux module support: – module management – driver registration – conflict resolution Module Management Supports loading modules into memory and letting them talk to the rest of the kernel Module loading is split into two separate sections: – Managing sections of module code in kernel memory – Handling symbols that modules are allowed to reference The module requestor manages loading of the requested, but currently unloaded modules; it also regularly queries the kernel to see whether a dynamically loaded module is still in use, and will unload it when it is no longer actively needed Driver Registration Allows modules to tell the rest of the kernel that a new driver has become available The kernel maintains dynamic tables of all known drivers, and provides a set of routines to allow drivers to be added to or removed from these tables at any time Registration tables include the following items: – Device drivers – File systems – Network protocols – Binary format Conflict Resolution A mechanism that allows different device drivers to reserve hardware resources and to protect those resources from accidental use by another driver The conflict resolution module aims to: – Prevent modules from clashing over access to hardware resources – Prevent autoprobes from interfering with existing device drivers – Resolve conflicts with multiple drivers trying to access the same hardware Signals Early minimal IPC (no info) mechanism Three distinct APIs asynchronous event notification system software analog of hardware interrupts original (buggy, unreliable) signals slightly differing semantics between Sys V, BSD reliable (Posix) signals real-time (Posix) signals Things you can with signals generate (send, raise): kill() deliver (receive, handle): during kernel to user transition block, mask: temporarily disable delivery (but not generation) ignore: throw away on delivery catch (handle): execute a user-supplied handler on delivery Signals: Basics Signals have names (macros) and numbers examples: SIGINT (2), SIGKILL (9), SIGPWR (30) kill –l lists platform assignments some are architecture and processor dependent SIGSTKFLT – coprocessor stack error (Intel) Signals can be generated by users via special shell character (control-c) via user-level commands (kill -9 1234) programs via system calls (kill(pid, sig)) the kernel (e.g in response to exceptions) Signals: Basics Signals in Linux Pending signals generated but not delivered may be blocked or not-blocked Regular signals “can’t count” regular: 1-31 (assigned specific functions) realtime: 32-64 (user assignable) generation of an already pending signal not recorded think of it as a single bit that is “set” on generation Realtime signals “queue” linked list of generated signals (up to some maximum) Signals: Basics Basic system calls Calls often operation on signal sets generate: kill(), rt_sigqueueinfo() block, unblock: sigprocmask(), rt_sigprocmask() check pending: sigpending(), rt_sigpending() establish handler: sigaction(), signal(), rt_sigaction() wait for signal: sigsuspend(), rt_sigsuspend() two element arrays of ints (64 bit bitmask) Blocking, pending, delivery blocked: delivery delayed until unblocked possible for signal to be blocked with no signal pending generated: pending for a short while even if unblocked unblocked pending signals: delivered on kernel to user transition delivery opportunities every timer interrupt (but only for current) Signals: Basics Masking signals current signal delivery masked during handler execution like interrupt masking handlers need not be re-entrant old, buggy semantics: current signal not masked Default actions all signals have a default action terminate dump – terminate and dump core ignore – throw away on delivery stop – control-z continue – possible to catch most signals establish user-specified handler SIGKILL, SIGSTOP can’t be caught, blocked, or ignored .. .Lecture? ?No. 38 Overview of today’s? ?lecture Loadable Kernel modules and device drivers Linux module management... Signals can be generated by users via special shell character (control-c) via user-level commands (kill -9 1234) programs via system calls (kill(pid, sig)) the kernel (e.g in response... generated but not delivered may be blocked or not-blocked Regular signals “can’t count” regular: 1-3 1 (assigned specific functions) realtime: 3 2-6 4 (user assignable) generation of an already