i n t main ( i n t a rgc , char  a rg v ) {
s i g n a l (SIGALRM, h a n d l e r ) ;
a l a rm ( 1 ) ;
whi l e ( 1 ) ;
}
By using the alarm(2) and signal(2) system calls, your shell can time the current running program. Handling asynchronous signaling is far more nuanced than described here: you should spend some time reading the entire man pages for these system calls and referencing online and printed resources (such as the books suggested on the course web page) to gain a better understanding of signals and signal handling.

1.3 The kill-switch

To terminate a running process, you will use the kill(2) system call. Despite its morbid name, the purpose of kill(2) is to deliver a signal to another process (not necessarily killing it). It will only kill the process if it delivers the right kind of signal. There is one such signal that you will use to do just that, SIGKILL. SIGKILL has the special property that it cannot be caught or ignored, so no matter the program your shell just executed, it must heed the signal

3.
1.4 Prompting and I/O

As previously stated, you must use only system calls, and nothing from the C standard library. This includes input and output functions such as printf(3) and fgets(3). Instead, you will use the read(2) and write(2) system calls. Your shell must prompt the user for input in a natural way, such as:

shredder#

Following the prompt, your program must read input from the user. You do not need to read input of arbitrary length; instead, you can truncate input to 1024 bytes, but you must gracefully handle input longer than that. Your shell should not crash in such situations.

1.5 Argument Restrictions

We do not require you to parse program arguments in your shell; that is, a user can provide any number of arguments but you do not actually have to parse them. However, your shell must still execute the program as intended. For example:

shredder# /bin/sleep 100
sleep: missing operand
Try ‘sleep --help' for more information.

Even though the user provided the argument "100", you are not required to pass this argument along to execve. Due to this restriction, you may ?nd it useful to write separate testing programs that exit after a speci?ed time (perhaps based on the SIGALRM example above).

Extra credit (5 pts): For extra credit, write a simple parser that will handle arbitrary arguments and pass them to execve appropriately. Note that you cannot use any function from the C standard library. This includes everything from string.h, so no use thinking about using strdup(3) or strtok(3) or their variants.

1.6 Shell arguments

Despite the fact that there is no requirement to handle arguments within your shell, the shell program itself (shredder) must take an optional argument, the execution timeout. If no argument is provided, then shredder (or whatever you're calling your shell) imposes no time restriction on executing processes.

You may be asking yourself, "Self, how am I going to convert a command line argument into an integer if I'm not allowed to use anything from the C standard library?" For this purpose alone, you may make a single call to atoi(3) or strtol(3) to convert command line input into an integer. You should check for errors in this conversion, e.g., when a user provides a character instead of a number. Extra credit (5 pts): For extra credit, implement your own version of atoi(3) that can handle arbitrary numbers within the 32-bit width of an integer.

1.7 Adding Your Own System Call

Once you have all this functionality working, you're going to get to exercise your creativity by adding your own new system call to the kernel that your shell will be able to execute. You can following along in the textbook (Problem 2.28) for how to do this, and you can implement the helloword system call that is suggested there, or you can be more creative and make a more functional call. You can put the calling function in the /bin directory along with programs such as cat and pwd, or leave it in your local directory, but show your program executing the command, and include the portion of your /var/log/kernel/warnings ?le that shows the system call being executed.

Ubuntu's kernel compilation process is not as straightforward as others, so you will want to use the following instructions for how to compile a kernel inside your VMimage.

2 Acceptable Library Functions

In this assignment, you may only use the following system calls:

 execve(2)
 fork(2)
 wait(2)
 read(2)
 write(2)
 signal(2)
 alarm(2)

 kill(2)
 exit(2)

You may also use the following non-system calls:
 malloc(3) or calloc(3)
 free(3)
 perror(3) for error reporting
 atoi(3) or strtol(3), but only once

Using any library function other than those speci?ed above will adversely affect your mark on this assignment. In particular, if you use the system(3) library function, you will receive a ZERO.

3 Error Handling

All system call functions that you use will report errors via the return value. As a general rule, if the return value is less than zero, then an error has occurred and errno is set accordingly. You must check your error conditions and report errors. To expedite the error checking process, we will allow you to use the perror(3) library function. Although you are allowed to use perror, it does not mean that you should report errors with voluminous verbosity. Report fully but concisely.

4 Memory Errors

You are required to check your code for memory errors. This is a non-trivial task, but a very important one. Code that contains memory leaks and memory violations will have marks deducted. Fortunately, the valgrind tool can help you clean these issues up. It can be installed inside your Linux VM (or native distro, if that's how you're running it). Remember that valgrind, while quite useful, is only a tool and not a solution. You must still ?nd and ?x any bugs that are located by valgrind, but there are no guarantees that it will ?nd every memory error in your code: especially those that rely on user input.

5 Developing Your Code

The best way to develop your code is in Linux running inside the virtual machine image provided to you. This way, if you crash the system, it is straightforward to restart. This also gives you the bene?t of taking snapshots of system state right before you do something potentially risky or hazardous, so that if something goes horribly awry you can easily roll back to a safe state. You may use the room 100 machines to run the Linux VM image within a Virtualbox environment, or run natively or within a VM on your own personal
machine. Importantly, do not use ix for this assignment.

The source code for your system call and the corresponding portion of the log ?le that shows it executing, as well as the code for the program that uses the system call.

Your code. This is not a joke: people have been known to forget to include it. Put all of your project ?les into their subdirectory called hw1 and make sure that your Makefile has a "make clean" command to clear out any object ?les and other unneeded intermediate ?les. Run "make clean" on this subdirectory.