Assignments-1 2022

My Operating System course has, generally, 4 to 5 assignments corresponding to each chapter of the book: "Operating Systems Design and Implementation, Third Edition", i.e., 1. Introduction, 2. Processes, 3. Input and Output, 4. Memory and 5. File Systems.
For the first assignment, I ask students to implement a simple system call. Generally, I divide the class into 10 teams which are given 10 different tasks.

General Instructions to the First Assignment

A system call makes a software interrupt. All teams must install docker and Shibata's work, visualize the switch from user to kernel mode following:

This link http://www.tldp.org/HOWTO/html_single/Implement-Sys-Call-Linux-2.6-i386/ teaches how to implement a system call on linux. Observe that we are dealing with the ARM architecture and not the i386 architecture.
Veja o relatorio da turma do Shibata: https://drive.google.com/file/d/1r_sqC3u2kAfBng7aKyzgZKW8r8uj3-Nq/view?usp=sharing

Follow the particular instructions to each team.

Team 1

Create an init process that opens a file (text.txt), reads and displays all lines and then, close the file. You must insert the text file, "text.txt", into rootfs.

Append screenshots of gdb to your report.

The system call "read" passes parameters to the kernel. Using gdb, show the ARM assembly code responsible to it and how the parameters passed to the kernel.

What happens when the "init" ends?

Team 2

Create an init process that forks it. The parent process continually prints "father" and the child, prints "child".

Append screenshots of gdb to your report.

The fork() returns zero to the child and the pid of the child to its parent. Using gdb, show how this number is passed to the user process. Append screenshots of gdb to your report.

Team 3

Create two processes: 1. init that will fork. The parent will continually print "1". The child will execve "child". 2. child, an executable file to be inserted into rootfs that will continually print "2".

Append screenshots of gdb to your report.

Using gdb, show how the parameters of execve are passed to the kernel: how the parameters are put in registers or on the stack, and how the kernel receives them. Append screenshots of gdb to your report.

Team 4

We presented the hello_world system call, but unfortunately, it is somehow undocumented. Create another hello_world system call, named hw2, that prints "hello world 2" to make sure you understood how hello_world was written. Google for more information and write a report about it.

Change the init, to call hw2.

Using gdb, run the hw2 step by step. Explain how hw2 leaves the kernel. Take screenshots of this happening.

Team 5

Let us implement a mechanism to pass data from one process to another, creating two system calls.

Create the system call save(number) which just saves a number inside the kernel.

Create the system call recover() that returns the number saved.
Create an init process that will fork into 2 processes: the parent will continually generate randomly a number and "save(number"). The child will continually number = recover() and print it. Check if it works.
Append screenshots to the report.

Team 6

Google how the ARM processor had discovered the instruction address soon after executed the instruction svc. The processor began to execute code in the file "entry-common.S" but how did the processor know about it? Search about it in the linux source code. You will have to study how the interrupt vector is created in the memory. Using gdb, print the instructions in interrupt vector.

Team 7

Many data structures are based on linked lists. The kernel makes use of them.
https://kernelnewbies.org/FAQ/LinkedLists
You may see that Shibata's team created system calls to push and pop data in a stack kernel using linked lists. Study the code and run it.
Change their work. Add two system calls to their work: queue_insert, queue_remove to create and deal with a queue instead of a stack using linked lists in the kernel. Make a init to play with your new system calls. Make two cases: 1. queue_insert and queue_remove works on the same linked list as stack_push and stack_pop; 2. on different linked lists.
Append screenshots to the report.

Team 8

Many data structures are based on linked lists. The kernel makes use of them. See:
https://kernelnewbies.org/FAQ/LinkedLists (ou ainda, Linux Kernel Development, Third Edition by Robert Love, cap 6).

Explain linked lists in the Linux Kernel not only to your classmates but also in your report.
You may see that Shibata's team created system calls to push and pop data in the kernel using linked lists. Study the code and run it.
Answer in your report:
The variable "count" contains the number of items in the stack, that is, a linked list in the kernel.
How does a user process may know about count?
Google sysfs (https://en.wikipedia.org/wiki/Sysfs) and explain how Shibata's work dealt with sysfs and "count". Put also in sysfs, the first and last element of the stack.
What does count_show and how is it called ? Consult: https://www.kernel.org/doc/Documentation/filesystems/sysfs.txt focusing in __ATTR_RO(name)
Create the process monitor, besides init, stack_pop (source: stack_pop.c) and stack_push, that continually displays the first, last elements of the stack and count. You may use "sleep".

Team 9

How does really the kernel get the system call number? Is it from the svc instruction or is it passed by some register? Using gdb, explain step by step how scno is gotten. Tip: Use C-x 2 to switch from source code to machine code. Change the linux source code to externalize the last system call number in sys directory. Observe that every system call is attended at the same place in entry-common.S (see the vector interrupt). There you can save the scno (system call number) in a variable. You may declare this variable in entry-common.S (create some .word variable in a data section). In order to externalize this variable in a sys directory, please read about it in Shibata's report. In order to test you modification, create an init file that calls some system calls and displays their numbers. Append gdb screenshots to your report.

Team 10

rootfs is the filesystem that contains the root (directory /). You can imagine that rootfs is your hard disk attached to a computer.
Create an init process that will:
- open the file text.txt (nonexistent) (w) : perhaps you will get an error if there is no space in rootfs.
- stay in loop writing one byte each time until you get an error. If "init" dies, then kernel panics (kernel dies).
Google how to create a rootfs with more space to enable text.txt.
If "init" dies then we get a kernel panic. Create (fork) an init child to make it so that init survives this kind of error.
Append gdb screenshots to your report

Pesquisar este blog

ARM Linux kernel Lab