A sample shellAnd scheduling algorithm written in C
Microsoft Word - Final Feb 20 Copy of Simple Shell Project - CMSC 421 - Spring 2022.docx Principles of Operating Systems CMSC 421 — Spring 2022 ____________________________________________________ Project 2: Simple Shell, /proc directory, CPU Scheduling Algorithms 100 points - see the rubric in blackboard for details CHANGELOG Nothing so far. Introduction In part 1 of this assignment, you will be writing a C program that works as a simple *nix shell program (*nix is shorthand for Unix or Linux machines). This part of the assignment only requires a few basic features of a shell and leaves out much of the functionality that more advanced shells such as Bash include. That is not to say that this assignment will be trivial — this is a 400-level course, after all. There are still several parts of this assignment that could trip you up, especially if you are not comfortable with lower-level C Programming. In part 2 of this assignment, you will be adding functionality to explore information from the /proc filesystem on Linux and to organize it in a way to present it to the user. This project is designed to help you get a warm-up with C, including topics that will be of importance going forward with your programming projects. This assignment is to be completed entirely in user-space — not within the Linux kernel source code and does not involve recompiling the kernel. You may complete this assignment outside of your VM for the class if you wish, however the TAs will be using the class Debian setup on a VM to grade the assignment (so you should at least compile and run your submitted assignment once in your VM to ensure it works before submitting it). You are not allowed to use the GL system (or any other shared environment) at UMBC to complete this assignment! You can get into real trouble for this! This assignment must be completed in the C programming language and must run on the Debian setup for this class. What is a shell? At its core, a shell is the interface between the linux kernel and users of the system. It is software that takes a string like ls -la from the user, formats it, then attempts to execute it. ls is an actual program located in /bin for instance. When you type ls in your shell, it finds that program and executes it. The shell itself does not execute any logic that says: for each file in directory: print filename [1]. It just invokes the program named ls. Modern shells have many extra bells and whistles, but you do not need to worry about them in this assignment. You do not have to create any GUIs, windows, or anything of that sort. [1]: While some shells do have such functionality built-in, your shell will not. Your shell will have two very specific features that are described below. Part 1 Requirements: For this assignment, you will only need to support a few very basic features of a full-fledged *nix shell. Specifically, you will need to have support for all of the following: 1. When your shell program first executes, it should take no arguments. While it is running, the shell shall present the user with a prompt at which they can enter commands. Upon the completion of a command, it shall prompt the user for a new command. 2. If executed with any arguments, the shell shall print an error message to stderr explaining that it does not accept any command line arguments and exit with an error return code (1). 3. The shell shall accept a command input of arbitrary length (meaning you cannot set a hard limit on command length). 4. The shell shall parse command-line arguments from the user's input and pass them to the program that the user requests to be started. The command to be called will be either specified as an absolute path to a program binary (like /bin/ls), as the name of a program that resides in a directory in the user's $PATH environment variable (like gcc), or as a relative path (for instance, if we are in the /usr directory, we could type bin/gcc as a command to run /usr/bin/gcc. In addition, your argument parsing code must properly handle escape sequences and quoting. That is to say that the input /bin/echo Hello\nWorld should be parsed into two pieces — the program name /bin/echo and one argument to that program containing the string "Hello World" with an actual newline character in place of the space (and no quotes). 5. The shell shall support a built-in exit command. This command shall accept zero or one argument. If provided with zero arguments, the shell shall exit with a normal exit status (that is to say, it will exit with a status of 0). If provided with one argument, it shall attempt to parse that argument as an integer. If this parsing fails, the command must be ignored, and the shell must prompt for another command. If the parsing succeeds, the shell shall exit with a status of whatever integer the argument parses. In either case of the shell exiting, it MUST clean up all memory it has allocated before exiting, along with ensuring that any child processes it has created have exited. 6. The shell shall not leak memory after it is done with it. The valgrind program can be your friend while debugging this program (unlike projects that are done in the kernel). We will also be using valgrind to test your implementation. You can find examples of multiple commands that may be used to test your code at the bottom of this page. NOTE: This is NOT an exhaustive list of commands that your shell must support. They are only given as examples. Any program installed on the VM should be runnable with your shell. You are not expected to support any of the following features: • Scripting control features (like if statements or loops). • Reading input from a file (like a shell script). • Support for pipes (including stdin/stdout redirection). • Built-in functionality that is often part of a shell (such as implementations of common commands like cd), other than what is outlined above for exit and in part 2. • Changing the current working directory in the shell. • Running programs in the background or resuming backgrounded processes. Part 2 /proc is a virtual file system in Linux. Most files in /proc appear to have zero length; however, you can view them using the cat command or an editor and see data in many of the files. These are not real files, but virtual files and symbolic links to files that exist elsewhere. Thus, they are not taking up real space on disk. Most files are read only, but others you can modify, and these will let you change the kernel's characteristics. Read the article at the following URL to learn more about the /proc virtual filesystem: https://www.linux.com/news/discover-possibilities-proc-directory/ . In part 2 of this assignment, you will explore some of the information available in the /proc filesystem. To create a process to use in this assignment, from another terminal run the top command in the background (type: "top &" without the quotes) and use the pid from this process for your exploration. You are required to add functionality to your shell program that reads information from the /proc filesystem and displays it on the normal stdout of the shell. This command shall accept a single command line argument that will be the name of the file from the /proc filesystem that the user wishes to read information from. Only a small subset of all of the files in /proc shall be available for use with this command, as detailed below. Your code will read information from the following files from the /proc filesystem: • cpuinfo — displays various CPU characteristics such as the CPU speed in MHz, cache size, CPU core count, address sizes, etc. • loadavg — displays the number of running processes and information about how much CPU time is being used currently (and over a couple different ranges). • filesystems -- displays the type of file systems that the operating system recognizes. • mounts – displays the mounted file systems. • pid/status (with pid being a process ID running currently on the system) — displays various characteristics of the running process, including how much memory it is using, the owner of the process, its state, etc. • pid/environ (with pid being a process ID running currently on the system) — displays information about the environment variables known by the specified process. • pid/sched (with pid referencing a process ID running currently on the system) — displays information about scheduling characteristics of the process specified. You may support more files in the /proc filesystem than those we have listed here, but you MUST at least support these. The proc command shall be implemented by opening the file specified within the /proc filesystem, reading all input from the file, and printing all of that information to stdout, followed by a newline character. Your shell then shall prompt for a new command, as usual. You are not required to parse the information you have read from the files in /proc at all prior to presenting it to the user. For instance, if you run the command proc cpuinfo, your output may look identical to running the command cat /proc/cpuinfo, however, you may not implement your code by actually running that command. You must implement the proc command by opening the appropriate file in the /proc filesystem, reading from it, and printing out its output to stdout. Return an appropriate error if needed. To sum up what you are expected to implement in this project: • Present the user with some sort of prompt at which the user may enter a command to execute. •