Managing Linux Kernel Modules: Signals, Conflicts, and Events, Slides of Advanced Operating Systems

Download Managing Linux Kernel Modules: Signals, Conflicts, and Events and more Slides Advanced Operating Systems in PDF only on Docsity!

Lecture No.

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

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.

 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

Driver Registration

Signals

 Early minimal IPC (no info) mechanism  asynchronous event notification system  software analog of hardware interrupts  Three distinct APIs  original (buggy, unreliable) signals  slightly differing semantics between Sys V, BSD  reliable (Posix) signals  real-time (Posix) signals  Things you can do 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

 Basic system calls  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()  Calls often operation on signal sets  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

Signals: System Calls

 kill(pid, sig)

 sigaction(sig, act, oact)

 signal()

 sigpending()

 sigprocmask()

 sigsuspend()