1 of 27

Advanced Interfacing �(OS, Driver, Kernel)

Dr A Sahu

Dept of Comp Sc & Engg.

IIT Guwahati

2 of 27

Outline

  • Mid semester Examination
  • Advance Peripheral interfacing
  • Standard Interfacing using PCI, SCSI, USB
  • OS, Device Driver
  • Kernel Module
  • Type of devices and drivers
  • Recommended text

3 of 27

Mid Semester Exam

  • Most of the student have attempted all the questions
  • End semester exam questions will be from 2nd part only (Courses after mid-sem)
  • 20 Students Stats: Average is 24 out of 50
  • Answer script of Mid-Semester will be shown 5th Oct 2010, Tuesday Class
    • We have to announce 1 week before
    • You will get 1 hour to check your paper for any discrepancy in evaluation
    • You can take back your answer script

​

​

​

4 of 27

Advance Peripheral interfacing

  • 8085/8086 based Interfacing
    • Understanding is Ok
  • Problem with Above
    • Advance Computer System
    • Standardization
    • PCI, SCSI, USB,
  • OS play important role in device interfacing
  • Kernel and Device driver
  • DMA, PIC, PIT
    • Controlling via Kernel Program (C program )

​

​

5 of 27

Linux Kernel Split View

Linux Device Driver by Jonhantan Corbet

6 of 27

Normal C/C++ programming

application

We would write most of this source-code

“app.cpp”

​

​

but we would call some library-functions

e.g., open(), read(), write(), malloc(), …

​

​

then our code would get ‘linked’ with

standard runtime libraries

​

(So this is an example of “code reuse”)

standard

“runtime”

libraries

call

ret

7 of 27

Normal C/C++ programming

application

standard

“runtime”

libraries

call

ret

user space

kernel space

Operating

System

kernel

​

syscall

sysret

Many standard library functions

perform services that require

executing privileged instructions

(which only the kernel can do)

8 of 27

Linux Kernel Modules

application

standard

“runtime”

libraries

call

ret

user space

kernel space

Operating System

kernel

​

syscall

sysret

module

Linux allows us to write our own

installable kernel modules

and add them to a running system

call

ret

9 of 27

Requirements/Benefits

  • An LKM has to be written using “C” -- but can include “inline” assembly language
  • An LKM runs in kernel-space – so it can do anything that the CPU supports
  • So an LKM can –
    • directly control the peripheral devices
    • modify the kernel’s scheduling algorithms
    • examine the kernel’s hidden data-structures

10 of 27

I assume you know

  • Familiar with using Linux (or UNIX)
  • Able to write programs in C (or C++)
  • Basic of Make and Makefile
  • Able to use an assembler
  • Acquainted with x86 architecture
    • General-purpose registers (EAX, EBX, …)
    • Categories of instructions (MOV, ADD, …)
    • Ways to address memory (direct, indirect,…)

11 of 27

Typical C layout

  • Basic structure of a C program:
    • Comment-banner (showing title and abstract)
    • Preprocessor directives (e.g., for header-files)
    • Global data-declarations (if they are needed)
    • Required ‘main()’ function (as the entry-point)
    • Can invoke ‘printf()’ (for ‘formatted’ output)
    • Optionally may define some other functions

​

12 of 27

Example program in C

#include<stdio.h>//Headerfor printf

​

int main(){

printf(“\n Hello world\n”);

return 0;

}

13 of 27

OS ‘Extensibility’

  • A modern OS needs the ability to evolve
    • Will need to support new devices
    • Will need to allow ‘bugs’ to be fixed
    • Will need to permit performance gains

​

  • Else OS may suffer early obsolescence!

14 of 27

Extensibility with Linux

Two mechanisms for ‘extensibility’:

​

  • ‘Open Source’ development

​

  • ‘Loadable’ kernel modules (LKMs)

15 of 27

Loadable Kernel Modules

  • Convenient technique for OS ‘extensibility’
  • Also allows us to study how kernel works
  • Kernel can be modified while it’s running
  • No need to recompile and then reboot
  • But inherently unsafe: any ‘bug’ can cause a system malfunction -- or complete crash!

​

16 of 27

‘Superuser’ privileges

  • Modifying a running kernel is ‘risky’

​

  • Only authorized ‘system administrators’

are allowed to install kernel modules

​

17 of 27

‘insmod’ and ‘rmmod’

  • We’re allowed to ‘install’ kernel objects:

$ /sbin/insmod myLKM.ko

​

  • We’re allowed to ‘remove’ kernel objects:

$ /sbin/rmmod myLKM

​

  • Anyone is allowed to ‘list’ kernel objects:

$ /sbin/lsmod

18 of 27

Creating a new LKM

  • You can use any text-editor (e.g., ‘vi’ or ‘emacs’) to create source-code (in the C language) for a Linux kernel module (i.e., an LKM)
  • But a kernel module differs from a normal C application program (e.g., no ‘main()’ function)
  • A kernel module cannot call any of the familiar functions from the standard C runtime libraries
  • For any LKM, two entry-points are mandatory (one for ‘initialization’, and one for ‘cleanup’)

19 of 27

Normal LKM structure

  • Resembles normal layout of C programs

but

  • Two ‘module administration’ functions [these are required]

plus

  • Appropriate ‘module service’ functions [these are optional]

20 of 27

Other LKM differences

  • Module uses ‘printk()’ instead of ‘printf()’
  • Includes the <linux/module.h> header-file
  • Specifies a legal software license (“GPL”)
  • Compilation requires a special ‘Makefile’
  • Execution is “passive” (it’s a ‘side-effect’)
  • Module has no restriction on ‘privileges’

​

21 of 27

Required module functions

  • int init_module( void );

// this gets called during module installation

​

  • void cleanup_module( void );

// this gets called during module removal

​

  • A newer syntax allows memory-efficiency:

module_init(my_init);

module_exit(my_exit);

22 of 27

Kernel module written in C

#include <linux/module.h> // for printk()

​

int init( void ){

printk( "\n Kello, everybody! \n\n" );

return 0;

}

​

void exit( void ){

printk( "\n Goodbye now... \n\n" );

}

MODULE_LICENSE("GPL");

module_init(init);

module_exit(exit);

23 of 27

Practice in lab

  • Download ‘mmake.cpp’ from class website and compile it with ‘make’ (or alternatively use: $ g++ mmake.cpp –o mmake )
  • Download the ‘kello.c’ source-file from the website, and compile it using ‘mmake’
  • Add the ‘kello.ko’ kernel-object to Linux using the Linux ‘/sbin/insmod’ command
  • Use ‘dmesg’ to view the kernel’s log-file
  • Remove ‘kello’ (with ‘/sbin/rmmod kello’)

24 of 27

Showing kernel messages

  • You can modify the ‘printk()’ text-string so its message will be sure to be displayed – -- it will be output to the graphical desktop

​

  • Here’s how you can do it:

printk( “<0> Hello, everybody! \n” );

​

​

This log-level indicates a ‘kernel emergency’

25 of 27

Summary

  • Download mmake.cpp and kello.c
  • Compile mmake.cpp using ‘make’
  • Then compile kello.c using ‘mmake’
  • Install ‘kello.ko’ (and see printk-message)
  • Remove ‘kello’ (to see another message)
  • Modify the ‘printk()’ statements in kello.c
  • Recompile and reinstall to view new info

26 of 27

Recommended texts

  • Corbet J, Rubini, and Kroah-Hartman, Linux Device Drivers (3rd Ed), ‘O’Reilly, 2005
  • George Pajari, Writing UNIX Device Drivers, Pearson Education India,2006
  • Maurice J Back, The design of the Unix OS, Prentice Hall India ,2007
  • Bovet and Cesati, Understanding the Linux Kernel (3rd Ed), ’ O’ Reilly (2006)
    • Soft copy of books available on course website

27 of 27

Thanks