M.

S RAMAIAH SCHOOL OF ADVANCED STUDIES

Department: Electronics and Computer Engineering

Course:
1. Real-time Embedded Systems
2. Computer Science and Networking
Module Code: ESD528
Module Title: Advanced System Programming
Module Leader: Shilpa Chaudhari

LAB

INSTRUCTIONS TO CANDIDATES:

1. All labs are compulsory to finish the module.

2. Two of you can share a system according to the availability of the systems in lab.
3. The last date of completion of the lab is the same day which it has been scheduled.
4. You are required to use Linux which is available in computer laboratory of the center.
5. You need to demonstrate any parts designed, and should answer queries made by the
module leader.
6. Feel free to discuss ideas with others in the class

December 2009
 Table of Content
Day 1
Part 1: Basic Commands
Part 2: The readelf utility
Day 2
Part 1: Linux source
Part 2: Toolchain building and Linux Porting on ARM
Day 3
Part 1: Linux Kernel Module
Day 4
Part 1: Linux Multitasking
Part 2: Linux Thread Programming
Part 3: Kernel module for tasklist
Day 5
Part 1: Cmosram device driver
Day 6
Part 1: Files
Part 2: System call Implementation
Day 7
Part 1: Memory management
Part 2: Memory management system calls
Day 8
Part 1: UART Device Driver Module
Part 2: The stash device driver
Part 3: Race condition and concurrency management
Day 9
Part 1: Interrupt handling
Part 2: TTY driver in Linux
Day 10
Part 1: Kernel timer system calls
Part 2: Kernel timer
Part 3: PCI driver
Part 4: Signal in Linux
Day 1: Basics of Linux Go back to Content
Part 1: Basic Commands
Read the slides given for this lab. Understand and execute the commands.
Part 2: The readelf utility
Write a program to print “hello world”. Create the executable using gcc compiler. Study
the ELF format file for it using readelf utility in Linux.

Day 2: Porting Linux on ARM Go back to Content

Part 1: Linux source
1. Go to www.kernel.org and get the latest stable tree. The sources are archived as tar files
compressed in both gzip and bzip2 formats.
bash> mkdir /home/student/yourdirectory
bash> cp linux-X.Y.Z.tar.bz2 /home/student/yourdirectory
bash> cd /home/student/yourdirectory
2. Obtain the source files by uncompressing and untarring the zipped tar ball. In the following
commands, replace X.Y.Z with the latest kernel version, such as 2.6.23:
bash> tar xvfj linux-X.Y.Z.tar.bz2
3. Observe how the source layout is organized. Go to the root of the source tree and list its
contents.
bash> cd linux-X.Y.Z
bash> ls
The directories branching out from the root of the code tree are as follows:
1. arch. This directory contains architecture-specific files. You will see separate
subdirectories under arch/ for processors such as ARM, Motorola 68K, s390, MIPS,
Alpha, SPARC, and IA64
2. block. This primarily contains the implementation of I/O scheduling algorithms for block
storage devices.
3. crypto. This directory implements cipher operations and the cryptographic API, used, for
example, by some WiFi device drivers for implementing encryption algorithms.
4. Documentation. This directory has brief descriptions of various kernel subsystems. This
can be your first stop to dig for answers to kernel-related queries
5. drivers. Device drivers for numerous device classes and peripheral controllers reside in
this directory. The device classes include character, serial, Inter-Integrated Circuit (I2C),
Personal Computer Memory Card International Association (PCMCIA), Peripheral
Component Interconnect (PCI), Universal Serial Bus (USB), video, audio, block,
Integrated Drive Electronics (IDE), Small Computer System Interface (SCSI), CDROM,
network adapters, Asynchronous Transfer Mode (ATM), Bluetooth, and Memory
Technology Devices (MTD). Each of these classes live in a separate subdirectory under
 drivers/. You will, for instance, find PCMCIA driver sources inside the drivers/pcmcia/
directory and MTD drivers inside the drivers/mtd/ directory.
6. fs. This directory contains the implementation of filesystems such as EXT3, EXT4,
reiserfs, FAT, VFAT, sysfs, procfs, isofs, JFFS2, XFS, NTFS, and NFS.
7. include. Kernel header files live here. Subdirectories prefixed with asm contain headers
specific to the particular architecture. So the directory include/asm-x86/ contains header
files pertaining to the x86 architecture, whereas include/asm-arm/ holds headers for the
ARM architecture.
8. init. This directory contains high-level initialization and startup code.
9. ipc. This contains support for Inter-Process Communication (IPC) mechanisms such as
message queues, semaphores, and shared memory.
10. kernel. The architecture-independent portions of the base kernel can be found here.
11. lib. Library routines such as generic kernel object (kobject) handlers and Cyclic
Redundancy Code (CRC) computation functions stay here.
12. mm. The memory management implementation lives here.
13. net. Networking protocols reside under this directory. Protocols implemented include
Internet Protocol version 4 (IPv4), IPv6, Internetwork Protocol eXchange (IPX),
Bluetooth, ATM, Infrared, Link Access Procedure Balanced (LAPB), and Logical Link
Control (LLC).
14. scripts. Scripts used during kernel build reside here.
15. security. This directory contains the framework for security.
16. sound. The Linux audio subsystem is based in this directory.
17. usr. This currently contains the initramfs implementation.
4. Wading through these large directories in search of symbols and other code elements can
be a tough task. Use cscope utility for locating declarations, definitions, regular expressions,
and more in the source tree. See the manual page for it.

Part 2: Toolchain building and Linux Porting on ARM

Make a group of 6/7 to do this lab. In this lab you may not have access to
create kernel image on all the system. You need to get exposure with kernel
compilation using few systems which wil be allocated to do this work.
1. Go to the top-level init/ directory and venture to make a small code change to the
initialization file main.c. Add a print statement to the beginning of the function,
start_kernel()
bash> cd init/
bash> vi main.c
asmlinkage void __init start_kernel(void)
{
 char *command_line;
extern struct kernel_param __start___param[], __stop___param[];
printk("Penguins are cute, but so are polar bears\n");
/* ... */
rest_init();
}
:wq
bash> cd ..
2. Follow the following instructions given for cross development environment creation for
ARM
• Copy given arm_tools.tar.gz file into /opt/ folder in Linux PC. In terminal move to the
/opt/ directory and run the following command.
#tar -zxvf arm_tools.tar.gz
• This will unpack the arm_tools.tar.gz into the same folder.
• Set the following path in the terminal.
#PATH=$PATH:/opt/arm_tools/bin/
• To compile application use the following command.
#arm-linux-gnu-gcc –s –static test.c –o test.o
3. Follow the instructions given in file (click here) for creation of the Linux kernel Image for
ARM
4. Follow the instructions given in file (click here) for creation of the initial RAM disk Image
for ARM
5. Follow the instructions given in file (click here) for porting the created Linux Kernel Image
on Linseed board available in the Lab
6. To derive maximum benefit from this module, familiarize yourself with the kernel by
frequently browsing the source tree and staring hard at the code. Follow the goings-on
in the kernel mailing list.
Day 3 Go back to Content
Part 1: Linux Kernel Module
1. Compile and run the given hello module by yourself.
• Add the module into the running kernel
• See the messages on the screen
• Kill the klogd
• Display the messages on the terminal using cat
2. Add the module parameters ‘whom’ you want to say hell and how many times in the hello
world module. And observe the result.
3. Learn the given cmos module which adds the proc entry. Compile and run the same.
4. Modify ‘cmos.c’ module’s ‘get_info()’ function by introducing a for-loop so that, in
addition to showing the current time, it will also display the full array of 128 bytes
currently stored in the CMOS memory.
Day 4 Go back to Content
Part 1: Linux Multitasking
Before starting this lab session read the manual pages of exec, wait and waitpid system calls.
Here the idea is to make student get expose to the system calls fork, exec and wait.
In this session initial examples are basic ones, but you will find some difficulty at the end. Try
to understand every instruction in the program.
The folder named Multitasking examples is organized in such a way that you have to execute
and understand the programs in ascending order. This is very important otherwise you will face
problems in understanding theory concepts. Try to use all the exec family of system calls.

After finishing this lab session students must be able to answer following questions.
1. What is fork system call is going to do?
2. What is the return value of the fork system call?
3. What is value of pid's of parent and child process.
4. What are the properties inherited by child process from parent.
5. What happens if the fork is called three times in a program?
6. If the process invokes fork system call infinite times, what is the effect on the system
performance?
7. After the fork system call, we have two identical processes parent and child. Now the
CPU has to execute either parent or child. Which process it executes. Why?
8. What are the return values of following system calls getpid(), getppid(), getuid(),
geteuid(), getgid(), getegid()
9. Study the sys/types.h header for pid_t data type. Why we have to use such data types.
10. What is the function of execl system call?
11. Try to use all the exec family of system calls.
12. After invoking execl system call, it will never return to original process. Why?
13. After invoking execl system call, what is the value of process id?
14. What is the function of the wait system call?
15. What is zombie and orphan process?
16. How to avoid zombies in a system?
17. Who will be the parent of orphan process?
18. Zombie process will not consume any system resources. How?

Extra Lab Questions:

1. Create 5 children from a common parent and ensure that children do not create their
own child processes
2. Create child processes in a fashion that each child creates a child and a chain of
processes is created (limit till 5 in a chain)
3. What happens if you try to create as many children from a common Parent (as in
question 1)? Observe and comment on the result.
4. Create a child process to execute "ls -lR /" using: a) execl b) execv
5. Implement a simple program-using fork () and wait () to avoid the Zombie state?
6. Write a simple program illustrating the use of wait system call in child?
7. Write a program to demonstrate the separate heap and stack memory area for both
parent and child processes?
 8. Write a simple program-using fork () and wait () in the parent? Observe the output by
using sleep () instead of the wait ()?
9. Create multiple forks in the parent and child? Observe the out put how many parent
created and how many child’s created?
10. Write a program for shell implementation.

Part 2: Linux Thread Programming:

Before starting this lab session read the manual pages of pthread_create, pthread_join and
pthread_detach. Here the idea is to make student get expose to the Thread creation and joining
the thread and detach the threads. Try to understand every instruction in the program. After that
read thread synchronization system calls such as pthread_mutex_init, pthread_mutex_attr,
pthread_mutex_lock etc...
The folder named Threads examples is organized in such a way that you have to execute and
understand the programs in ascending order. This is very important otherwise you will face
problems in understanding theory concepts. For compilation, you need to use the thread library
as follows:
gcc -lpthread filename.c

Extra Lab Questions

1. Write the program to create the two threads and join threads? Observe the multitasking?
2. Write a program for producer-consumer, implemented with semaphores. All integers
between 0 and 9 should be printed exactly twice, once to the right of the arrow and
once to the left. */
3. Write a program by using pthread_join and pthread_detach. Comment pthread_join and
observe the output. Comment pthread_detach and observe the output.

Part 3: Kernel module for tasklist

1. Different versions of the 2.6 Linux kernel use slightly different definitions for the task-
related kernel data-structures (e.g., the 2.6.10 kernel used a smaller-sized ‘thread-info’
structure than 2.6.9 kernel did) So, by using the C ‘sizeof’ operator, can you quickly
create an LKM that will show us:
• the size of a ‘task_struct’ object (in bytes)?
• the size of a ‘thread_info’ object (in bytes)?
2. Learn the given tasklist module that lets us create a pseudo-file (named ‘/proc/tasklist’)
for viewing list of all currently active tasks. Compile and run it.
3. Modify the ‘tasklist.c’ module so that it will display a list of only those tasks which are
‘kernel threads’? (i.e., task->mm == 0). How many ‘kernel threads’ on your list?
Day 5 Go back to Content
Part 1: Cmosram device driver
1. Learn the given cmosram device driver for read, write and lseek methods. Compiler and
run it by yourself.
2. Rewrite the LKM demo-module named 'cmosram.c' using the new 'cdev' kernel-interface
functions (described in "Linux Device Drivers (3rd Ed)" textbook, pages 55-57) instead of
the older-style register_chrdev()' and 'unregister_chrdev()' functions. As explained in
LDD3, the "new" way requires your driver to include the <linux/cdev.h> header-file, and to
allocate storage for an object of type 'struct cdev' which your driver must initialize and then
'register' by calling the 'cdev_add()' function, then later must 'unregister' using the
'cdev_del()' function.
3. The read() and write() callback functions in the ‘cmosram.c’ device-driver only transfer a
single byte of data for each time called, so it takes 128 system-calls to read all of the RTC
storage-locations! Can you improve this driver’s efficiency, by modifying its read() and
write() functions, so they’ll transfer as many valid bytes as the supplied buffer’s space
could hold?
4. Add code to your module's initialization function in modified cmosram device driver which
creates the required '/dev/cmos' device-file allowing both read-and-write access to all users,
and add code to your module's cleanup function to 'unlink' this device-file when your
module is removed from the kernel. This will be more convenient for your module's users
than requiring that they must ask their System Administrator to setup that device-file or
else install a separate module which performs that step.
5. Add code to your modified cmosram device driver module that will implement a pseudo-
file named '/proc/cmos', in addition to the device-file named 'dev/cmos', so a user can use
the Linux 'cat' command to quickly display the current values in the 128 cmos memory
locations, using hexadecimal format, without needing to write a special application-
program that performs the binary-to-ascii translations.
Day 6 Go back to Content
Part 1: Files
This lab session deals with file i/o related system calls.
Reading Exercise.
1. Read the open(2),read(2) and write(2) system calls.
2. Read the fcntl(2) system call carefully.
3. Read the header /usr/include/bits/fcntl.h and analyse the bits.
The folder named FS examples is organized in such a way that you have to execute and
understand the programs in ascending order. This is very important otherwise you will face
problems in understanding theory concepts.

Exercise: Combine error.c pathalloc.c and create static library mylib.a, link this library at
compile time.

Extra Lab Questions

1. Write a program to check a file is read-only, write only, executable?
2. Write simple programs by using statvfs (), statfs () find the details about the file system,
where your home directory is residing. Observe the details about your file system
3. Write a program to check the root file is execute or not and create one file to give the
permissions?
4. Write a simple program to check how many arguments pass to the file?
5. Write a simple program using lockf and lseek, sleep function in the file?
6. Write a program to implement ls command?
7. How to find the size of the file from user mode in your program code?

Part 2: System call Implementation

In this lab session you will implement new system call by name mysyscall(int a, int b)
which return sum of the two integers.
There are several ways to create, install and execute a system call. The best is the one that
isn't concerned with low-level details like context switching and doesn't code any routines
in assembly language. This can be done through the use of the _syscallN macro in the
linux/include/asm/unistd.h directory; it is expanded in assembly, but the operating system
takes care of details. It uses the int 0x80 to transfer execution control to the kernel. One
possible problem is this macro can expand to an existing function, so care must be taken;
otherwise, you will overwrite the existing function.
Now you must choose a name for every function you are planning to implement. You can
check the existing ones in your source tree at linux/arch/i386/kernel/entry.S and
linux/include/asm/unistd.h. In entry.S, they are at the end, and in unistd.h, at the beginning.
Checking these files will also help you get an idea of how to create a prototype of a system
call. While checking, you will see that each call is associated with one number. This
number is passed in the %eax processor register indicating the number of arguments, and
each argument of the system call (a function) is passed in %ebx, %ecx, %edx, %esi
or %edi--up to five arguments on Intel platforms. The macro definitions corresponding to
each _syscallN, depending on the value of N, can be found in unistd.h. More on the internal
 workings can be found in various files under linux/arch/i386/, because we will leave the
``dirty work'' to the operating system.
Now let's see how to implement a new system call using the syscallN macro in the simplest
possible way. Let's make a system call sysSum, which accepts two integer arguments and
returns the sum of the two. Also, it uses printk, which is similar to printf except that it
works on the kernel level, so we will see when our function is called.
Steps for Implementing New System Calls:
1. To do this, edit a randomly selected file (for example, the file linux/ipc/sem.c), and at the
end, add the following lines:
asmlinkage int sysSum(int a, int b)
{
printk("calling sysSum");
return a+b;
}
2. Then edit unistd.h and add
#define __NR_sysSum 171

171 is the next in numerical order.

3. In near the end of entry.S in 2.4 kernel and /arch/i386/kernel/syscall_table.S in 2.6 kernel,
add

.long SYMBOL_NAME(sysSum)

Finally, increment by one the number that is the last line:

.space (NR_syscall-172)*4

If you don't match number and name in both files, you will get an ``undefined reference to
sysSum'' error message. If you have a working kernel, you have to be careful only about
incrementing the numbers by one and correctly writing your function name. At this point,
you have added your system call; now you should get the new kernel with it.
4. Compile the kernel using the same steps as you followed in day 2 and reboot the system
using this newly created kernel to invoke the system call from a user program.
5. This simple program tests the newly created system call:
#include <linux/unistd.h>
_syscall2(int, sysSum, int,a,int,b)
main(){
printf("the sum of 4+3 is %d\n",sysSum(4,3));
}
The include line indicates where the _syscall definition is located. The next line says our
system call has a return type of int and two arguments of type int.
6. To compile, use the command
gcc -I ~/linux/include
to instruct the compiler to use our include file. After execution, you will see messages: first
the one from sysSum, then the one from the test program.
 Day 7 Go back to Content
Part 1: Memory management
1. Learn the given cr3.c module which displays the value of cr3 and cr4 registers in proc
file named cr3. Compile and run it. Observe the result.
2. Learn the given pgdir.c module which creates a pseudo-file that lets users see a visual
depiction of the CPU’s current ‘map’ of ‘virtual memory’. Compile and run it. Observe
the result.
3. Learn the given dram.c device driver module which implements a Linux character-
mode device-driver for the processor's installed physical memory. Compile and run it.
Observe the result.
4. Learn the given mm.c module which allows users to see values stored in some of the
‘mm_struct’ object’s important fields. Compile and run it. Observe the result.
5. Learn the given vma.c module which lets user see the list of VMAs for a task. Compile
and run it. Observe the result.
6. Compare vma demo to ‘/proc/self/maps’
7. Try running the given ‘domalloc.c’ demo. It lets you see how a call to the ‘malloc()’
function would affect an application list of ‘vm_area_struct’ objects. Compile and run it.
Observe the result. NOTE: Install our ‘vma.ko’ kernel-object before running
‘domalloc’

Part 2: Memory management system calls

This lab session deals with Linux memory management system calls.
Reading Exercise.
1. Read manual pages formalloc, calloc, realloc, alloc, free calls.
2. Read the mmap, munmap, msync, mlock and munlock system call carefully.
The folder named MM examples is organized in such a way that you have to execute and
understand.

Extra Lab Questions:

1. What is dangling pointer and memory leak concepts? By using this concepts implement
the programs?
2. Write a program by using memory allocation functions?
Day 8 Go back to Content
Part 1: UART Device Driver Module
1. Study the UART device driver module. Compile and run it. Observe the result.
Part 2: The stash device driver
2. Learn the stash.c device driver. Compile and run it. Observe the result.
3. Add a ‘get_info()’ function to stash driver to create a pseudo-file (named ‘/proc/stash’)
that will show the current contents of the ringbuffer (if any) and the current values for
the ‘head’ and ‘tail’ buffer-indices. Don’t forget: use ‘create_proc_read_entry()’ in your
‘init_module()’ function, and use ‘remove_proc_entry()’ during ‘cleanup’
Part 3: Race condition and concurrency management
1. Observe the problems with the stash device by concurrently accessing it from different
terminals.
2. Learn the given newstash.c driver which removes the concurrency problem of stash
device driver. Compile and run it. Observe the result
3. Learn the given con1.c multithreaded program. Compile and run it. Observe the result -
synchronization problem between the threads of the process.
4. Learn the given con2.c multithreaded program which has spinlock mechanism for
synchronizing between the threads of the process. Compile and run it. Observe the
result - no synchronization problem between the threads of the process but more time.
5. Learn the given con3.c multithreaded program which has nanosleep mechanism.
Compile and run it. Observe the result. Use the Linux ‘time’ command to compare the
performance of ‘con3’ and ‘con2’
6. Revise the ‘con3.c’ program so that a thread will ‘yield’ if it cannot immediately
acquire the mutex.
7. Identify the 'race conditions' that are present in the original 'cmosram.c' driver-code,
and eliminate them from your revised driver, by using the 'rtc_cmos_read()' and
'rtc_cmos_write()' functions (prototyped in the <asm/mc146818rtc.h> header-file).
Day 9 Go back to Content
Part 1: Interrupt handling
1. Learn the given showidt.c program which displays the 126 IDT entries of Pentium PC.
Compile and run it. Observe the result.
2. Learn the given smpinfo.c program which lets users view the MP Floating Pointer and
MP Configuration Table data-structures in the workstation’s ROM-BIOS memory.
Compile and run it. Observe the result.
3. Determine how many ‘buses’ are present in the machines? HINT: Use ‘smpinfo.c’
kernel module and the fact that each bus is described by an entry of type 1 in the MP
Configuration Table
4. Learn the given ioapic.c module which lets users view the current contents of the I/O
APIC Redirection-Table registers. Compile and run it. Observe the result.
5. The keyboard’s interrupt is ‘routed’ by the I/O-APIC Redirection Table’s second entry
(i.e., entry number 1). Determine its interrupt ID-number on the Linux systems? HINT:
Use ‘ioapic.c’ kernel-module
6. Learn the given ioremap.c module which asks the kernel to set up a ‘mapping’ of the
page at physical address 0xFEE00000 into the kernel’s virtual address-space. This is
the page where each processor’s Local-APIC resides. Compile, run and observe result.
7. Try modifying the ‘ioremap.c’ module so it accesses the Local-APIC Identification
Register using a C assignment-statement instead of calling the ‘ioread32()’ function.
Example: int id_register; // declare local ‘int’ variable
register = *(int *)(lapic+0x20); // input value
8. Examine the effect on page-table entries when the ‘ioremap_nocache()’ function
replaces the ‘ioremap()’ function in the ‘ioremap.c’ module

Part 2: TTY driver in Linux

1. Learn noncanon.c which demonstrates ‘noncanonical’ tty mode. Compile and run it.
Observe the result.
2. Modify this simple C program so that it will print its “Hello” message in colors and be
located in the center of the screen:
#include <stdio.h>
int main( void )
{
printf( “Hello, world! \n” );
}
Day 10 Go back to Content
Part 1: Kernel timer system calls
This lab session deals with Linux kernel timer functions and system calls.
Reading Exercise.
1. Read manual pages ctime, gettimeofday and setittimer calls.
The folder named Timer functions examples is organized in such a way that you have to
execute it and understand it.

Extra Lab Questions:

3. Implement the program to display the current time of the day by using ctime ()
function?
4. Implement the program of setitimer function?

Part 2: Kernel timer

1. Learn the trytimer.c module which shows how a Linux kernel timer can be used to
perform a periodic action (such as using ‘printk()’ to issue a message every time the
time expires, then restart the timer. Compile and run it. Observe the result.
2. Learn the ‘tryworkq.c’ module which shows the delayed work (consists of simply
printing a message) to the kernel’s logfile -- you can view by typing the ‘dmesg’
command. Compile and run it. Observe the result.
3. Learn the ‘defermsg.c’ modules that show display a message within a desktop window
after a 10-second delay. Compile and run it. Observe the result.
4. Learn the foo.c driver that show the use of workqueues to perform actions later, either
as soon as a ‘process context’ is available, or after a prescribed time.
5. Modify the ‘watchfoo.c’ to remove the two ‘problems’ –
I. first excess cpu usage – solution is use the ‘top’ utility which shows high
percentage of the available CPU time is being consumed by ‘watchfoo’. You can add
a kernel timer to the ‘foo.c’ driver to curtail this excessive reading
II. Second loop-termination
6. Modify ‘foo.c’ (call it ‘timedfoo.c’) as follows
• Create an integer flag-variable (‘ready’) as a global object in the module
• When the ‘read()’ function gets called, it should sleep until ‘ready’ equals
TRUE; it should set ‘ready’ equal to FALSE when it awakens, but should set a
timer to expire after 1/10 seconds
• The timer’s action-function should set ‘ready’ back to TRUE, then wake up any
sleeping tasks
Hint:
• You need a wait-queue (so your driver’s ‘reader’ tasks can sleep on it)
• You need a timer action-function
 • You need to organize your timer-function’s data-items into a single structure
(because the timer-function has only one argument)
• Your timer-function must do two things:
• Change ‘ready’ to TRUE
• Wake up any ‘sleepers’
Part 3: PCI driver
1. Learn the given vram.c driver module which lets users view the graphics controller’s
PCI Configuration Space parameter-values. Compile and run it. Observe the result. Use
the given rotation.c programs to use the vram driver.

Part 4: Signal in Linux

In this session you will learn signals concept in a process such as sigaction, sigprocmask,
sigemptyset, sigdelset, sigfillset etc.
Before starting this lab session read the manual pages of signal system call. Try to understand
all the 32 signal types. After that you start executing these programs.
Before executing any program go through the source code and understand the concept then
execute.
Signals are very important in an operating system, read the manual pages of all the signal
system calls.

After finishing this lab session student must be able to answer the following questions.
1. What are signals?
2. What are links? Discuss and use different types of links?
3. How do you determine the type of the file?
4. What is the difference between read and execute permission of a directory?

Extra Lab Questions:

5. What is SIG_DFL handler and write a simple program by using SIG_DFL?
6. How to kill the signal by using kill function and kill the signal SIGINT?
7. Write a program by using signal function and alarm?
4. Implement a program by using alarm, and simulate using fork, sleep, and signal?
Observe the output of the program?