1. Trang chủ
  2. » Công Nghệ Thông Tin

Advanced Operating Systems: Lecture 38 - Mr. Farhan Zaidi

14 3 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 14
Dung lượng 364,58 KB

Nội dung

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

Ngày đăng: 05/07/2022, 12:35