OS-344 Assignment-2A
OS-344 Assignment-2A
Instructions
Modern consoles support many features that help users work more efficiently. In the first part of the
assignment, you will implement two basic features that will hopefully allow you a more efficient
workflow when testing your code.
In the first part you will extend the kernel to support Caret navigation (text cursor navigation).
In the second part you will add partial support of "Shell History Ring".
In the current xv6 console, pressing the keyboard keys ← or → will result in their appropriate
ASCII signs to appear on the console. When working inside your Linux terminal those keys will
cause the caret to move to the appropriate location (left or right) allowing the user to edit what he
wrote more efficiently.
In the first part of your assignment, you will need to implement caret navigation.
Notice:
End line must result in moving to the next line no matter where the caret is and it’s ascii
value entered at the end of the buffer.
When editing from the middle of a buffer you must shift the text accordingly.
History of past shell commands allows terminal users to evaluate multiple requests very fast without
writing the entire command. In this part of the assignment, you will have to implement the history
feature and the ability to easily update the console to fit the needed history. In modern operating
systems the history is implemented in the shell, to allow for a simple implementation you will
implement history in kernel. Your implementation should support a maximum of 16 commands. To
do so you can add: #define MAX_HISTORY 16 to your code.
Once history is implemented, we need a way to access the history. You will implement two
mechanisms to do so:
1) The ↑ / ↓ keys will need to retrieve the next / last item in the history respectively. The item
retrieved should now appear in the console.
Input:
char * buffer ‐ a pointer to a buffer that will hold the history command,
Output:
2 ‐ historyId illegal
Once this is implemented add a “history” command to the shell user program (see sh.c) so that it
upon writing the command a full list of the history should be printed to screen like in common.
● A good place to start for both 1.1 and 1.2 is the console.c file.
● Notice that this feature will only work on the QEMU console and not on the terminal. Running
QEMU in noxmode for ssh is not advised while testing part 1.
Task 2: Statistics
In future tasks you will implement various scheduling policies. However, before that, we will
implement an infrastructure that will allow us to examine how these policies affect performance
under different evaluation metrics.
The first step is to extend the proc struct (see proc.h). Extend the proc struct by adding the
following fields to it: ctime, stime, retime and rutime. These will respectively represent the
creation time and the time the process was at one of following states: SLEEPING,
READY(RUNNABLE) and RUNNING.
➢ Tip: These fields retain sufficient information to calculate the turnaround time and waiting time
of each process.
Upon the creation of a new process the kernel will update the process’s creation time. The fields
(for each process state) should be updated for all processes whenever a clock tick occurs (you can
assume that the process’ state is SLEEPING only when the process is waiting for I/O). Finally, care
should be taken in marking the termination time of the process (note: a process may stay in the
‘ZOMBIE’ state for an arbitrary length of time. Naturally this should not affect the process’
turnaround time, wait time, etc.). Since all this information is retained by the kernel, we are left with
the question of extracting this information and presenting it to the user. To do so, create a new
system call wait2 which extends the wait system call:
Input:
int * retime / *rutime / *stime ‐ pointers to an integer in which wait2 will assign:
*retime : The aggregated number of clock ticks during which the process waited
*rutime : The aggregated number of clock ticks during which the process was running
*stime : The aggregated number of clock ticks during which the process was waiting for I/O (was
not able to run).
Output:
1 ‐ upon failure
Submission instructions
Place all the files including Makefile that you modified for each part into separate subfolders
named as Task[1 or 2] and put all of them into a zip file, with the name being your group
number (say, G10.zip).
Create a patch of your modified files.
report.pdf should contain a detailed description of all of your implementation including
screenshots of code and output.
Further, you must describe your test cases in some detail, and the observations you made
from them.
--End of Assignment-2A--