rephrase this document with the same style using a Microsoft Word … due in an hour and 30 mins
Description
The Project report deals with followings
· Flow of control for system calls in xv6
· Adding a new system call
· Accessing specific information for each active process
· Use of conditional compilation to enable and disable kernel features.
Deliverables
The following features are added to xv6:
A system call tracing facility that, when enabled, prints the following information to the console:
A new system call, date (), that returns the current UTC date and time.
A new user command, date, that prints the current UTC date and time to standard output.
Each process now records the value of the ticks’ global variable when that process is created. This
value is used to calculate
elapsed time for each process.
A modification to the existing control {p mechanism, which displays debugging information, to include
elapsed time for each process.
Implementation
Paste your Code Lines here
System Call Tracing Facility
The code for the system call tracing facility was conditionally compiled using the PRINT SYSCALLS ag
in the
Makefile (line XX).
Lines XX -YY
Lines XX -YY
Date System Call
user.h.
The user-side function prototype for the date() system call was added (line XX). The
system call takes a pointer to a user defined rtctime struct.
The prototype is:
int date(struct rtcdate*);
The File date.h contains the rtcdate definition.
syscall.h.
The date() system call number was created by appending to the existing list (line XX).
syscall.c.
Modified to include the kernel-side function prototype (line XX); an entry in the function
dispatch table syscalls [] (line XX); and an entry into the syscallnames [] array to print the
system call name when the PRINT SYSCALLS ag is defined. All prototypes here are defined as taking
a void parameter as the function call arguments are passed into the kernel on the stack. Each
implementation (e.g., sys date()) retrieves the arguments from the stack according to the syntax of
the system calls.
usys.S.
The user-side stub for the new system call was added (line XX). This stub uses a macro that
essentially just traps into kernel-mode.
sysproc.c.
Contains the kernel-side implementation of the system call in sys date() (lines XX {
YY). This routine removes the pointer argument from the stack and passes it to the existing routine
cmostime() in lapic.c (line XX). The pointer argument is expected to be a struct rtctime*. The
routine cmostime() cannot fail so a success code is returned by sys date().
Date User Command
The date user command is implemented in the file date.c. This command invokes the new date () system
call to fill in the supplied rtcdate struct; passed by reference. The command then displays the date and
time information on standard output. The return code from the system call is checked and handled as a
user program does not know if a system call will succeed or fail.
Control-p Modifications and Elapsed Time
The control- p console command prints debugging information to the console. The following modifications
were made to capture and display elapsed time as part of the existing control-p debugging information.
proc.h
. A new field was added to struct proc named
uint start_ticks
for storing the time of
creation (in ticks) for each process (line XX).
proc.c.
The routine allocproc() (line XX) was modified to correctly set start ticks on process
creation.
procdump().
This routine in proc.c was modified to:
Print a header (line XX) to the console.
· Calculate the elapsed time since process creation (lines XX – YY). This section calculates
· elapsed time as seconds and hundredths of seconds as the granularity of the ticks variable is
at hundredths of a second.
· Include the elapsed time in the display of process information on the console (line XX).
Testing
Testing screenshots
System Call Tracing Facility
I tested this feature by modifying the Makefile to turn on PRINT SYSCALLS ag, then booting the xv6
kernel, and observing the following output:
Testing screenshots
The system call trace correctly displays invoked system calls. The standard output is interleaved with
the trace output. The output \init: starting sh” is printed by the init() process (init.c) and the \$” is
printed by the shell process (sh.c).
This test PASSES.
(Your results)
Date System Call and User Command
I am going to use the date command to test both the date() system call and date command, as I can’t
directly invoke a system call from the shell. My testing will invoke my date command in xv6 and then
invoke the corresponding Linux date command and see if the former closely matches the latter.
Testing screenshots
The output from my date command closely matches the output of the Linux date command, except
for a slight discrepancy in the number of seconds. This discrepancy is expected as it takes non-zero time to
exit xv6. This test shows that the date command works correctly, along with the date system call, since
the command prints out all of the information extracted by the system call.
This test PASSES.
Control-p and Elapsed Time
The test for these will be split into two phases. My first test will show that control-p is outputting the
correct information, while my
second test
will use the first test to show that the elapsed time is correct.
Here is the output of the first test:
Testing screenshots
The control{p output indicates that there are two processes running in xv6. This is correct. The first
process is the initial process, here named
\init”,
with a PID of 1. The second process is the shell, named
\sh”,
with a PID of 2 (as it is the second process created). Note that the PCs appear to be correct, as
they correspond to valid addresses in the kernel.asm file and the code for printing this information was not
modified.
This sub-test PASSES.
second test
For the second test, I will restart the kernel, and then press control-p several times, each press being
within one second of the other. The results are shown below:
Testing screenshots
The elapsed time for the
init
process is 0.64 seconds higher than that of the
sh
process in all outputs.
This makes sense as
init
starts before sh. Also, note that the elapsed times are steadily increasing by
about one second with the same 0.64 s difference between
init
and sh.
This sub-test PASSES.
Because all sub-tests passed, this test PASSES.