Assignment 3 - 2022

 

Team 1: blocked processes in blocking_device

Read and experiment phase 3 work in http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html

Make the pid of all processes blocked in blocking_device visible in /sys/show_blocked.

Test it. You may run "read_test  &" as many times as you wish.
tip: Do you know what is a file in sysfs? It just exports some information from the kernel. In order to create "show_blocked",  you do not have to create any additional data structure (such as an array) inside the kernel. You will have to look for the pid of all blocked processes looking some data structure that already exists.

Notice that when you have many "read_test" processes waiting for a char, when one char arrives from keyboard, all processes are put to run. Change this behavior, and give one char to just one process, keeping all others blocked.

Team 2: systemtap: I/O monitoring

You are not using Shibata's work.

systemtap is a script language developed by RedHat that runs in kernel mode. It collects and displays kernel data (or even user data) as the user wishes. See https://sourceware.org/systemtap/SystemTap_Beginners_Guide/

The script https://sourceware.org/systemtap/SystemTap_Beginners_Guide/traceio2sect.html shows how to monitor I/O activity on a specific device.

For this assignment, use the centos distribution because it deals much better with SystemTap. 

Run this script to monitor different devices in your computer, specially, your mouse. Monitor your mouse in a X windows environment. Who uses it? 

Create a C program that opens the mouse device and continually reads it and displays the character received. At the same time, monitor the mouse use by the systemtap script.

Team 3: A bare linux drive

Read and experiment phase 3 work in  http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html . Create the bare drive /dev/bare_device by http://www2.pcs.usp.br/~jkinoshi/2020/Exp8_revisada_17_10_19.doc

in Shibata's work. 

Experiment it for reading and writing as:

echo "asdf" > /dev/bare_device

cat /dev/bare_device

Shibata's team had to enable devtmpfs to work with /dev as /dev isn't present in rootfs. 

Answer: how does linux kernel, using devtmpfs, populate /dev ?

It is possible, however, to have /dev/bare_device working without the devtmpfs kernel option enabled.
Study it, disable the devtmpfs kernel option and make another /dev/bare_device work.
There are two ways to insert a driver in a kernel - 1) creating the kernel with the driver or 2)through insmod (using a shell). If you choose option one, you will have to:

• compile the driver as you compile the init (outside busybox). Follow https://github.com/tiagoshibata/linux/blob/master/sys_blocking_dev/sys_blocking_dev.c
• insert the driver in the kernel when making it; change the kernel to make it happen. Follow  https://github.com/tiagoshibata/linux/blob/master/sys_blocking_dev/Makefile and https://github.com/tiagoshibata/linux/blob/master/Makefile
• create /dev/ in rootfs; see 4.3.1 in https://www.tldp.org/HOWTO/Bootdisk-HOWTO/buildroot.html

Team 4: console; input

Read and experiment phase 3 work in http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html
We noticed that the qemu uses the driver amba-pl011 for input because it boots as if a uart terminal is connected to the versatile board. Study how the driver writes characters and receives it. Make the driver counts the number of received characters by modifying the interrupt handler.  Printscreen the gdb when it enters in the interrupt handler after a key is pressed. Printscreen showing the number of received characters.

Team 5: pressed key

Read and experiment phase 3 work in http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html

Create /sys/pressed_key which counts the number of interruptions from keyboard. Tip: see when the keyboard interrupts. Insert breakpoints near the vector interrupt to capture the keyboard interrupt but be careful to avoid the super frequent timer interruptions.
tip: did you understand what is sysfs? See: team 8 in http://linux-kernel-lab.blogspot.com/2018/04/assignments-1.html 

Team 6: clock and timer

Read and experiment phase 3 work in http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html

The manual of the versatile board is on: 

https://static.docs.arm.com/dui0225/d/DUI0225D_versatile_application_baseboard_arm926ej_s_ug.pdf

It uses the timer:

http://infocenter.arm.com/help/topic/com.arm.doc.ddi0271d/DDI0271.pdf

This timer configuration (addresses and ports) are handled by ~/Downloads/pcs3746-sistemas-operacionais/1/linux/drivers/clocksource/timer-sp804.c

Questions:

1. How to be sure that timer-sp804.c is running on your linux? Insert a breakpoints on functions of this file to understand how they are called and why. Explain it.

2. Change some parameters of the timer to see how they affect the linux, i.e., modify (write) some timer registers. For instance, make the timer interruptions never happens, or make it happens in a very low frequency. Compare how different the actual time (seconds) is from our real world before and after changing the timer behavior.

team 7: interruption source

Read and experiment phase 3 work in http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html

When an interruption happens, it is necessary to determine who caused it. Determine where does it happen in the Linux kernel. Insert breakpoints and take screenshots.

Display the last hardware interrupt in /sys/last_interrupt (tip: do you know what is sysfs?)

Declare a variable in the kernel, such as last_interrupt.

In order to take the last interrupt, perhaps, you will have to make some change in a assembly code because the interrupt vector and its treatment at the most basic level is in assembly. In this case, use a STR.
It is very likely that the clock interrupt will happen a lot, so you may update last_interrupt each 1M (or more) clock interrupts.

team 8: processes waiting keyboard

Read and experiment phase 3 work in http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html

Study: http://www.linusakesson.net/programming/tty/ and specially what is line discipline.

Create /sys/waiting_key which shows the pid of the processes that are waiting for some key to be pressed.
The queue of processes waiting for the keyboard must be in the line discipline driver. You will have to create functions to get this queue and show when the file /sys/waiting_key is being read.

Team 9: console,output

Read and experiment phase 3 work in http://linux-kernel-lab.blogspot.com/2018/06/blocking-device.html

We noticed that the qemu uses the driver amba-pl011 for input because it boots as if a uart terminal is connected to the versatile board. Study how the driver writes characters and receives it.
Make the driver counts the number of transmitted characters by modifying the driver.  Printscreen the gdb when it enters in the interrupt handler after a key is pressed. Printscreen showing the number of transmitted characters.

Team 10: systemtap: time in kernel and user space

You are not using Shibata's work.

systemtap is a script language developed by RedHat that runs in kernel mode. It collects and displays kernel data (or even user data) as the user wishes. See https://sourceware.org/systemtap/SystemTap_Beginners_Guide/

The script
https://sourceware.org/systemtap/SystemTap_Beginners_Guide/threadtimessect.html
shows how to determine the amount of time any given thread is spending in either kernel or user-space.
For this assignment, use the centos distribution because it deals much better with SystemTap. 

Create a C program that uses a lot of CPU and another which uses a few (for instance: insert sleep in your code). Monitor both programs in your virtual machine. Give 2 cores to your virtual machine running centos. How does it handle both programs?
Change the systemtap scritp in order to monitor just your processes. Insert prints in your script to understand what is happening.