Character Device Driver ( Pre req: Multi tasking, threading)

Dr A SahuDept of Comp Sc & Engg.

IIT Guwahati

Outline• Character Device Driver – Characteristics and functionality– Basic IO functions

• Multi tasking (pre requisite to do this)• Examples Drivers (in detail)• ADC, Printer, Tape drive

Linux Char Vs block$cd /dev/block/$ ls –l rwxrwxrwx 1 root root 7 2010-08-12 21:32 1:0 -> ../ram0lrwxrwxrwx 1 root root 7 2010-08-12 21:32 1:1 -> ../ram1…lrwxrwxrwx 1 root root 8 2010-08-12 21:32 1:15 -> ../ram15lrwxrwxrwx 1 root root 6 2010-08-13 03:02 11:0 -> ../sr0lrwxrwxrwx 1 root root 8 2010-08-13 03:02 7:0 -> ../loop0lrwxrwxrwx 1 root root 8 2010-08-13 03:02 7:1 -> ../loop1….rwxrwxrwx 1 root root 8 2010-08-13 03:02 7:7 -> ../loop7lrwxrwxrwx 1 root root 6 2010-08-13 03:02 8:0 -> ../sdalrwxrwxrwx 1 root root 7 2010-08-13 03:02 8:1 -> ../sda1….lrwxrwxrwx 1 root root 7 2010-08-13 03:02 8:5 -> ../sda5

Mount –o loop CD.iso /mnt/cdrom

# Formats, mounts, and sets permissions on my 16MB ramdisk $/bin/mount /dev/ram0 /mnt/rd

Linux Char Vs block$cd /dev/char/$ ls –l lrwxrwxrwx 1 root root 8 2010-08-13 03:02 10:144 -> ../nvramlrwxrwxrwx 1 root root 15 2010-08-12 21:32 10:223 -> ../input/uinputlrwxrwxrwx 1 root root 9 2010-08-13 03:02 10:227 -> ../mceloglrwxrwxrwx 1 root root 7 2010-08-13 03:02 10:228 -> ../hpetlrwxrwxrwx 1 root root 7 2010-08-12 21:33 10:229 -> ../fuselrwxrwxrwx 1 root root 11 2010-08-13 03:02 10:231 -> ../snapshotlrwxrwxrwx 1 root root 6 2010-08-12 21:32 10:232 -> ../kvmlrwxrwxrwx 1 root root 13 2010-08-12 21:32 10:57 -> ../vboxnetctllrwxrwxrwx 1 root root 10 2010-08-12 21:32 10:58 -> ../vboxdrvlrwxrwxrwx 1 root root 21 2010-08-13 03:02 10:59 -> ../network_throughputlrwxrwxrwx 1 root root 18 2010-08-13 03:02 10:60 -> ../network_latencylrwxrwxrwx 1 root root 18 2010-08-13 03:02 10:61 -> ../cpu_dma_latencylrwxrwxrwx 1 root root 17 2010-08-13 03:02 10:62 -> ../mapper/controllrwxrwxrwx 1 root root 14 2010-08-13 03:02 10:63 -> ../vga_arbiter

Linux Char Vs block$cd /dev/char/$ ls –l lrwxrwxrwx 1 root root 6 2010-08-13 03:02 1:1 -> ../memlrwxrwxrwx 1 root root 7 2010-08-13 03:02 1:11 -> ../kmsglrwxrwxrwx 1 root root 9 2010-08-13 03:02 1:12 -> ../oldmemlrwxrwxrwx 1 root root 15 2010-10-06 22:42 116:10 -> ../snd/pcmC1D0clrwxrwxrwx 1 root root 16 2010-10-06 22:42 116:11 -> ../snd/controlC1lrwxrwxrwx 1 root root 12 2010-08-12 21:32 116:2 -> ../snd/timerlrwxrwxrwx 1 root root 10 2010-08-12 21:32 116:3 -> ../snd/seqlrwxrwxrwx 1 root root 15 2010-08-12 21:32 116:4 -> ../snd/pcmC0D1plrwxrwxrwx 1 root root 15 2010-08-12 21:32 116:5 -> ../snd/pcmC0D0plrwxrwxrwx 1 root root 15 2010-08-12 21:32 116:6 -> ../snd/pcmC0D0clrwxrwxrwx 1 root root 13 2010-08-12 21:32 116:7 -> ../snd/hwC0D3lrwxrwxrwx 1 root root 16 2010-08-12 21:32 116:8 -> ../snd/controlC0lrwxrwxrwx 1 root root 15 2010-10-06 22:42 116:9 -> ../snd/pcmC1D0plrwxrwxrwx 1 root root 7 2010-08-13 03:02 1:3 -> ../nulllrwxrwxrwx 1 root root 15 2010-08-13 03:02 13:32 -> ../input/mouse0lrwxrwxrwx 1 root root 15 2010-08-13 03:02 13:33 -> ../input/mouse1lrwxrwxrwx 1 root root 13 2010-08-13 03:02 13:63 -> ../input/mice

Linux Char Vs block$cd /dev/char/$ ls –l lrwxrwxrwx 1 root root 15 2010-08-13 03:02 13:64 -> ../input/event0lrwxrwxrwx 1 root root 15 2010-08-13 03:02 13:65 -> ../input/event1lrwxrwxrwx 1 root root 15 2010-08-13 03:02 13:66 -> ../input/event2rwxrwxrwx 1 root root 13 2010-08-13 03:02 162:0 -> ../raw/rawctllrwxrwxrwx 1 root root 7 2010-08-13 03:02 1:7 -> ../fulllrwxrwxrwx 1 root root 9 2010-08-13 03:02 1:8 -> ../randomlrwxrwxrwx 1 root root 18 2010-08-13 03:02 189:0 -> ../bus/usb/001/001lrwxrwxrwx 1 root root 18 2010-08-13 03:02 189:128 -> ../bus/usb/002/001lrwxrwxrwx 1 root root 18 2010-08-13 03:02 189:256 -> ../bus/usb/003/001lrwxrwxrwx 1 root root 18 2010-08-13 03:02 189:384 -> ../bus/usb/004/001lrwxrwxrwx 1 root root 18 2010-08-13 03:02 189:512 -> ../bus/usb/005/001lrwxrwxrwx 1 root root 18 2010-08-13 03:02 189:513 -> ../bus/usb/005/002lrwxrwxrwx 1 root root 18 2010-08-13 03:02 189:640 -> ../bus/usb/006/001lrwxrwxrwx 1 root root 18 2010-10-06 22:42 189:649 -> ../bus/usb/006/010lrwxrwxrwx 1 root root 18 2010-08-13 03:02 189:768 -> ../bus/usb/007/001lrwxrwxrwx 1 root root 10 2010-08-13 03:02 1:9 -> ../urandomlrwxrwxrwx 1 root root 12 2010-08-13 03:02 202:0 -> ../cpu/0/msrlrwxrwxrwx 1 root root 12 2010-08-13 03:02 202:1 -> ../cpu/1/msrlrwxrwxrwx 1 root root 12 2010-08-13 03:02 202:2 -> ../cpu/2/msrlrwxrwxrwx 1 root root 14 2010-08-13 03:02 203:0 -> ../cpu/0/cpuidlrwxrwxrwx 1 root root 14 2010-08-13 03:02 203:1 -> ../cpu/1/cpuidlrwxrwxrwx 1 root root 14 2010-08-13 03:02 203:2 -> ../cpu/2/cpuid

Linux Char Vs block$cd /dev/char/$ ls –l lrwxrwxrwx 1 root root 6 2010-08-13 03:02 21:0 -> ../sg0lrwxrwxrwx 1 root root 6 2010-08-13 03:02 21:1 -> ../sg1lrwxrwxrwx 1 root root 12 2010-08-13 03:02 226:0 -> ../dri/card0lrwxrwxrwx 1 root root 17 2010-08-13 03:02 226:64 -> ../dri/controlD64lrwxrwxrwx 1 root root 10 2010-08-13 03:02 250:0 -> ../hidraw0lrwxrwxrwx 1 root root 10 2010-10-06 22:42 250:1 -> ../hidraw1lrwxrwxrwx 1 root root 10 2010-08-13 03:02 251:0 -> ../usbmon0…lrwxrwxrwx 1 root root 10 2010-08-13 03:02 251:7 -> ../usbmon7lrwxrwxrwx 1 root root 14 2010-08-13 03:02 252:0 -> ../bsg/0:0:0:0

lrwxrwxrwx 1 root root 7 2010-08-13 03:02 254:0 -> ../rtc0lrwxrwxrwx 1 root root 6 2010-08-13 03:02 29:0 -> ../fb0lrwxrwxrwx 1 root root 7 2010-08-13 03:02 4:0 -> ../tty0…lrwxrwxrwx 1 root root 8 2010-08-13 03:02 4:38 -> ../tty38lrwxrwxrwx 1 root root 10 2010-08-13 03:02 5:1 -> ../consolelrwxrwxrwx 1 root root 7 2010-08-13 03:02 5:2 -> ../ptmxlrwxrwxrwx 1 root root 6 2010-08-13 03:02 7:0 -> ../vcs..lrwxrwxrwx 1 root root 7 2010-08-13 03:02 7:1 -> ../vcs6lrwxrwxrwx 1 root root 7 2010-08-13 03:02 7:128 -> ../vcsa..lrwxrwxrwx 1 root root 8 2010-08-12 21:32 7:134 -> ../vcsa6lrwxrwxrwx 1 root root 7 2010-08-12 21:32 7:2 -> ../vcs2lrwxrwxrwx 1 root root 7 2010-08-12 21:32 7:3 -> ../vcs3lrwxrwxrwx 1 root root 7 2010-08-12 21:32 7:4 -> ../vcs4lrwxrwxrwx 1 root root 7 2010-08-12 21:32 7:5 -> ../vcs5lrwxrwxrwx 1 root root 7 2010-08-12 21:32 7:6 -> ../vcs6lrwxrwxrwx 1 root root 11 2010-08-12 21:32 99:0 -> ../parport0

Basic char-driver components

init

exit

fops

function

function

function

. . .

Device-driver LKM layout

registers the ‘fops’

unregisters the ‘fops’

module’s ‘payload’ is a collection of callback-functions having prescribed prototypes AND

a ‘package’ of function-pointers

the usual pair of module-administration functions

Character Device Drivers• Character device drivers normally perform I/O

in a byte stream. • Examples of devices using character drivers

include tape drives and serial ports. • Character device drivers can also provide

additional interfaces not present in block drivers, – I/O control (ioctl) commands– memory mapping – device polling.

Standard File-I/O functions

int open( char *pathname, int flags, … ); int read( int fd, void *buf, size_t count ); int write( int fd, void *buf, size_t count ); int lseek( int fd, loff_t offset, int whence ); int close( int fd ); (and other less-often-used file-I/O functions)

root# mknod /dev/cmos c 70 0Read /dev/cmos as a FILE

Multi-tasking

• Modern operating systems allow multiple users to share a computer’s resources

• Users are allowed to run multiple tasks• The OS kernel must protect each task from

interference by other tasks, while allowing every task to take its turn using some of the processor’s available time

Stacks and task-descriptors

• To manage multitasking, the OS needs to use a data-structure which can keep track of every task’s progress and usage of the computer’s available resources (physical memory, open files, pending signals, etc.)

• Such a data-structure is called a ‘process descriptor’ – every active task needs one

• Every task needs its own ‘private’ stack

What’s on a program’s stack?

Upon entering ‘main()’:• A program’s exit-address is on user stack• Command-line arguments on user stack• Environment variables are on user stackDuring execution of ‘main()’:• Function parameters and return-addresses• Storage locations for ‘automatic’ variables

Entering the kernel…

A user process enters ‘kernel-mode’:• when it decides to execute a system-call• when it is ‘interrupted’ (e.g. by the timer)• when ‘exceptions’ occur (e.g. divide by 0)

Switching to a different stack

• Entering kernel-mode involves not only a ‘privilege-level transition’ (from level 3 to level 0), but also a stack-area ‘switch’

• This is necessary for robustness:e.g., user-mode stack might be exhausted

• This is desirable for security:e.g, privileged data might be accessible

What’s on the kernel stack?

Upon entering kernel-mode:• task’s registers are saved on kernel stack

(e.g., address of task’s user-mode stack)

During execution of kernel functions:• Function parameters and return-addresses• Storage locations for ‘automatic’ variables

Supporting structures

• So every task, in addition to having its own code and data, will also have a stack-area that is located in user-space, plus another stack-area that is located in kernel-space

• Each task also has a process-descriptor which is accessible only in kernel-space

A task’s virtual-memory layout

User space

Kernel space

User-mode stack-area

Task’s code and data

Privilege-level 0

Privilege-level 3

process descriptor andkernel-mode stack

Shared runtime-libraries

The Linux process descriptor

task_struct

state*stack

flags

*mm

exit_code

*user

pid

*files

*parent

mm_struct

*pgd

pagedir[]

user_struct

signal_struct

*signal

files_struct

Each process descriptorcontains many fields and some are pointers to other kernel structures

which may themselves include fields that point to structures

Something new in 2.6

• Linux uses part of a task’s kernel-stackpage-frame to store ‘thread information’

• The thread-info includes a pointer to the task’s process-descriptor data-structure

Task’s kernel-stack

Task’s thread-infopage-frame aligned

Task’sprocess-descriptor

struct task_struct 8-KB

Tasks have ’states’

From kernel-header: <linux/sched.h>

• #define TASK_RUNNING 0• #define TASK_INTERRUPTIBLE 1• #define TASK_UNINTERRUPTIBLE 2• #define TASK_STOPPED 4• #define TASK_TRACED 8• #define TASK_NONINTERACTIVE 64• #define TASK_DEAD 128

Fields in a process-descriptorstruct task_struct {

volatile long state;void *stack;unsigned long flags;struct mm_struct *mm;struct thread_struct *thread;pid_t pid;char comm[16];

/* plus many other fields */ };

Finding a task’s ‘thread-info’

• During a task’s execution in kernel-mode, it’s very quick to find that task’s thread-info object

• Just use two assembly-language instructions:

movl $0xFFFFF000, %eaxandl %esp, %eax

Ok, now %eax = the thread-info’s base-addressThere’s a macro that implements this computation

Finding task-related kernel-data

• Use a macro ‘task_thread_info( task )’ to get a pointer to the ‘thread_info’ structure:

struct thread_info *info = task_thread_info( task );

• Then one more step gets you back to the address of the task’s process-descriptor:

struct task_struct *task = info->task;

The kernel’s ‘task-list’

• Kernel keeps a list of process descriptors• A ‘doubly-linked’ circular list is used• The ‘init_task’ serves as a fixed header• Other tasks inserted/deleted dynamically• Tasks have forward & backward pointers,

implemented as fields in the ‘tasks’ field• To go forward: task = next_task( task );• To go backward: task = prev_task( task );

Doubly-linked circular list

init_task(pid=0)

newesttask

…

next_task

prev_task

Maybe a big /proc file…

• We can’t know ahead of time how many tasks are active in our system – this will depend on many varying factors, such as who else is logged in, which commands have been issued, whether we’re using text-mode console or graphical desktop

• So it’s perfectly possible our pseudo-file might ‘overflow’ its kernel-supplied buffer!

How to avoid buffer-overflow

• Our module’s ‘get_info()’ callback-function has four parameter-values passed to it by the kernel:

• char *buf - address of a small kernel buffer• char **start - address of a pointer variable• off_t offset - current offset of file-pointer• int buflen - size of the kernel buffer

• The initial conditions are: offset == 0 and *start == NULL

• Kernel’s behavior will vary if we modify *start

Normal case

• We expect the ‘/proc’ file to deliver a small amount of text-data (not more than would fit in the kernel-supplied buffer (e.g., 3KB)

• So we make no change to ‘*start’• Then kernel will deliver the data it finds in the

buffer it had supplied to ‘get_info()’ • The kernel will not call ‘get_info()’ again

(unless our file is closed and reopened)

Alternative case

• Our ‘get_info()’ function modifies the value of the (initially NULL) ‘*start’ pointer – for example, maybe assigning it the address of some buffer we’ve allocated, or even assigning the address of the kernel-buffer:

*start = buf;

• In this case, the kernel will again call our module’s ‘get_info()’ function, provided we returned a nonzero function-value before!

The benefit

• Knowing about this alternative option, we can design our ‘get_info()’ function so that it delivers a big amount of data in several small-size chunks, never overflowing the size-limitations on the kernel’s buffer

• We just need to think carefully about the differing senarios under which ‘get_info()’ will be repeatedly called

First pass

• The value of ‘offset’ will be zero• We set *start to a buffer-address where we

place a positive number of data-bytes• Kernel delivers those bytes to the ‘reader’,

taking them from the *start address, then advances the file-pointer by that amount

• Kernel calls our ‘get_info()’ again, but with a non-zero ‘offset’ value this time!

Final time

• When our ‘get_info()’ function has finally finished delivering all the desired data to the file’s ‘reader’, and still we receive yet another ‘get_info()’ call, then we simply return a function-value equal to zero, telling the kernel that the data has been exhausted -- and so not to call again!

Our implementationstruct task_struct *task; // ‘global’ variables’ values remembered

int my_get_info( char *buf, char **start, off_t offset, int buflen ){

int len = 0;

if ( offset == 0 ) // our first time through this function{task = &init_task; // start of circular linked-list}

else if ( task == &init_task ) return 0; // our final pass

// put some data into the kernel-supplied bufferlen += sprintf( buf+len, “pid=%d \n”, task->pid );*start = buf; // tell kernel where to find data, and to call again

task = next_task( task ); // advance to next node of circular listreturn len; // and tell kernel how far to advance

}

‘Kernel threads’

• Some tasks don’t have a page-directory of their own – because they don’t need one

• They only execute code, and access data, that resides in the kernel’s address space

• They can just ‘borrow’ the page-directory that belongs to another task

• These ‘kernel thread’ tasks will store the NULL-pointer value (i.e., zero) in the ‘mm’ field of their ‘task_struct’ descriptor (mm:mem map)

Thanks