Please write a stat.c file for the following instructions:

Introduction: The xv6 OS is an educational OS designed by MIT for use as a teaching tool to give students hands-on experience with topics such as shell organization, virtual memory, CPU scheduling, and file systems.

use the following commands to git clone the xv6 into your VM for this assignment in a terminal:

sudo apt-get update sudo apt-get upgrade sudo apt-get install git zip build-essential sudo apt-get install gdb-multiarch qemu-system-misc sudo apt-get install gcc-riscv64-linux-gnu sudo apt-get install binutils-riscv64-linux-gnu git clone https://github.com/mit-pdos/xv6-riscv.git xv6 chmod 700 -R xv6

To start xv6 run the following command from terminal: make qemu

Resources: The following resources provide more in depth information regarding xv6. They include the xv6 reference book, tools for installing, and guidance to better understand xv6. 1. xv6

Reference Book: https://pdos.csail.mit.edu/6.828/2020/xv6/book-riscv-rev1.pdf 2.

Lab Tools Guide: https://pdos.csail.mit.edu/6.828/2020/tools.html 3.

Lab Guidance: https://pdos.csail.mit.edu/6.828/2020/labs/guidance.html

Project: Complete the following steps. Implement a series of new system calls: getmem() getstate() getparentpid() getkstack () Implement a user level C program, stat.c, to call the new system calls.

System Calls: Implement the following system calls. getmem() Returns memory size of the calling process getstate() Returns the current state (SLEEPING, RUNNING, or RUNNABLE) of the calling processes. getparentpid() Returns process identification (PID) of the calling processs parent. getkstack() Returns address of kernel stack.

The system call to get the process identification number (PID) of the current process, getpid() and uptime() are already included in xv6. As such, it may be easier to start with display only the PID and uptime values. You can find a detailed explanation of these in Chapter 1 Operating System Interfaces of the xv6 textbook. To simplify the coding, we will not acquire a lock.

Setting up a System Call A system call must be both available in the user space and kernel space. It must be available in user space so that it can be used by other programs and it must be available in kernel space so it has permission to access resources that are prohibited from user mode.

User Mode Files (xv6/user) When we call a system call, we are actually invoking a trap in the kernel. However, we wish to avoid writing assembly code or traps in our programs. So wrappers, written in a high-level language, will wrap around the assembly code which will allow us to use them as functions.

FILE: user.h

Listed in this file are all the functions that are available in user space as a wrapper for the system calls. The functions are written in C and it looks very similar to a function prototype. It is important to make sure that the arguments declared with this function matches the arguments when the function is defined (they are defined in sysproc.c which will be discussed later.)

ACTION: Edit user.h to add a line for the new system calls. Hint; Look at how other system calls are declared and follow the pattern that best suits each new system call.

FILE: usys.pl This is a Perl file. This is where the system call is actually performed via Perl to RISC-V assembly.

A brief walk-through of the code: Line 11: Emit $name (system call) to symbol table (scope GLOBAL). Line 12: A label with the $name. Line 13: Load immediate (system call number) which specifies the operation the application is requesting into register a7. Line 14: System calls are called executive calls (ecall). Perform ecall (safe transfer of control to OS). Exception handler saves temp regs, saves ra, and etc. Line 15: Return.

The code that follows after this is repeatedly calling for all the different system calls. ACTION: Edit usys.pl to add a line for the new system calls. Hint: Look at how other system calls are declared and follow the pattern.

Kernel Mode Files (xv6/kernel) The files below are where the system call is made available to the kernel.

FILE: syscall.h This file is the interface between the kernel space and user space. From the user space you invoke a system call and then the kernel can refer to this to know where to find the system call. It is a simple file that defines a system call to a corresponding number, which will be later used as an index for an array of function pointer. ACTION: Edit syscall.h to add a line for the new system calls.

FILE: syscall.c This file has two (2) sections where the system call must be added. Starting around line 83, is a portion where all the functions for the system calls are defined within the kernel. ACTION: Edit syscall.c to add a line for the new system calls (two places each). Look at how other system calls are declared and follow the pattern.

FILE: sysproc.c This is where we are defining all of the functions in kernel space. Here you will find how the other system calls are defined. Because the new system calls are very simple they may only one line. However, it still needs to be declared in this file. ACTION: Edit sysproc.c to add a function for the new system calls. Do not overthink these functions. You should look at the other system calls definitions to derive your solution.

User-Level - Test Program Implement and test the user level program to call the new program to call a series of system calls to display information about the current process. FILE: user/stat.c

Edit the Makefile to add your new user -level user program so that it will be compiled along with the rest of the user programs. This is very similar to how we added our hello user program. You only have to do this once for each new user program created. As before, you can build xv6 as follows: make clean make qemu

Once working, the user program should look similar to the following:

$ stat Process PID: 5 Memory Used: 16384 Proc State: RUNNING Uptime (ticks): 11 Parent PID: 2 Page Tble Addr: FFFF9000

The actual information displayed will vary between systems