procinfo() returns 0 on success; - 1 otherwise (e.g., NULL input pointer, fail to copy results back to the caller process , etc.)

Tips:

.    To count the number of processes, see kernel/proc.c and   kernel/proc.h

.    To check the system call count, you will need to modify kernel/syscall.c

.    Even if sysinfo() is the very first syscall you make in your user-level program, you will notice that a couple of other syscalls have been already issued. This is normal; recall how a process is

created (e.g., fork, exec, etc).

.     printf uses syscalls to display output. So you may see an unexpected increase in syscall count when printf is inserted in-between sysinfo or procinfo.

.    To check the amount of free memory pages in the system , see kernel/kalloc.c. Xv6 manages free pages in a linked list (kmem.freelist) .

.    To retrieve a pointer type input in a syscall, use argaddr(). The kernel cannot directly write     data to the userspace memory; you will need to use copyout() to do so. Search the kernel code to find how to use copyout (e.g., kernel/file.c or sysfile.c) .

.    The kernel function  myproc() returns the PCB of the current process.

.    To implement Part 2, you need to manage syscall count on a per-process basis. Initialize new per- process data fields in allocproc().

.    You can find the amount of memory used by each process from its PCB.

.    To check if your syscall is reporting the correct number of free or used memory, allocate memory in your user-level program before making the system call.

How to test:

To test your implementation , you can create a user-level program using these syscalls under various scenarios . Below is just an example (user/lab1_test.c):

This user program calls sysinfo() and creates N child processes, each of which allocates a specified amount of memory and calls procinfo(). Once all child processes print procinfo(), the parent process calls sysinfo() again .

For example, if you want to test with 2 child processes with each allocating 65Kbytes of memory, type:

$ lab2_test 65536 2

(the first argument is the bytes of memory to be allocated by each child process, and the second argument is the number of child processes to be created) .

Running example (you may need to press ‘enter’ or any key after each line is printed):

$ lab1_test 65536 2

[sysinfo] active proc: 3, syscalls: 49, free pages: 32564

[procinfo 4] ppid: 3, syscalls: 10, page usage: 21

[procinfo 5] ppid: 3, syscalls: 10, page usage: 21

[sysinfo] active proc: 5, syscalls: 241, free pages: 32510

$ $ $ $ lab1_test 65000 1

[sysinfo] active proc: 3, syscalls: 345, free pages: 32564

[procinfo 10] ppid: 9, syscalls: 10, page usage: 20

[sysinfo] active proc: 4, syscalls: 474, free pages: 32538

$ $ $

What to submit:

You need to submit the following:

(1)  The entire XV6 source code with your modifications (‘make clean’ to reduce the size before submission)

(2) A report (must be in PDF; no other formats will be accepted) including:

a)   The list of all files modified

b)   A detailed explanation on what changes you have made and screenshots showing your work and results

c)   A detailed description of XV6 source code (including your modifications) about how the info system call is processed, from the user-level program into the kernel code, and then back into the user-level program.

d)   Link to the demo video on the very first page of the report.

e)   A brief summary of the contributions of each member

(3) A demo video showing that all the functionalities you implemented works as expected, as if you were demonstrating your work in-person. For instructions about recording, refer to the Demo

Video Recording Guide.

How to submit:

Upload the demo video to your own Google Drive (or YouTube) and create a shareable link. Add this link to the first page of the report. Pack the report and source code files into a single zip file, and upload it to    eLearn/Canvas.

Only one person of your team needs to submit the file.