Everyone:
Welcome to CSE 30341 Operating System Principles, which (as the syllabus states) is a course that "introduces all aspects of modern operating systems", including topics such as "process structure and synchronization, interprocess communication, memory management, file systems, security, I/O, and distributed files systems". What this means is that we will be exploring the key ideas behind operating systems such as Linux, Windows, and macOS and studying the underlying abstractions these systems provide to user applications.
For this week, you need to setup your GitLab repository, read about basic hardware and operating system concepts, and submit your responses to the Reading 00 Quiz.
Last semester, most of you took the CSE 20289 Systems Programming course where you learned about how to use a Unix system and how to program applications in that environment. Throughout the course, you experienced and practiced the Unix Philosophy:
Write programs that do one thing and do it well.
Write programs to work together.
Write programs to handle text streams, because that is a universal interface.
You did this by writing shell scripts, Python applications, and utilities in C. You even wrote a webserver that took advantage of multiple processes!
In this class, we will take the next step and explore what data structures, algorithms, and mechanisms are necessary at the operating system level to support such applications. That is, we will discuss how the operating system kernel provides different abstractions that allow us to safely and efficiently execute multiple programs that communicate with each other while accessing different hardware resources. In short, we will uncover the magic that powers the Unix Philosophy.
For this course, we will focus on three main ideas:
Virtualization: How does the operating system represent the underlying hardware resources?
Concurrency: How does the operating system coordinate multiple streams of execution?
Persistence: How does the operating system organize data?
To explore these topics and apply the concepts learned in class, you will implement six programming projects throughout the semester: implement a file copying utility, implement a basic Unix shell, implement a message bus, implement malloc, implement memcache, and implement a filesystem. These projects will require some design work, extensive testing, and utilization of the skills you learned in both CSE 20289 Systems Programming and CSE 20312 Data Structures.
Additionally, you will have weekly reading assignments (the first one is below). These will automatically be graded by the continuous integration system provided by GitLab.
Of course, there will be two exams: a midterm exam before Fall Break and a final exam during Finals Week.
For this week, your first task is to setup your GitLab repository by doing the following:
Fork the class assignments repository: cse-30341-fa19-assignments
Configure the Settings of your repository such that:
Under General > Project description (optional), record your name and netid.
Under Permissions > Project visibility, select Private.
Add the instructional staff to your repository:
Under Project members*, select the Add member** tab.
Under Project members > Select member to invite, enter in the following accounts:
William Diederich (@wdiederi)
Under Project members > Choose a role permission, select Maintainer.
Under Project members > Access expiration date, select
December 31, 2019 (2019-12-31
).
Once this is done, you can clone your git repository to your local machine:
$ git clone https://gitlab.com/$USERNAME/cse-30341-fa19-assignments.git
Note: If you have not done so already, you should consider setting up SSH Keys on GitLab to enable password-less pushing and pulling.
You are responsible for ensuring that your GitLab assignments repository is in proper order, which means you have the correct settings and permissions set. Failure to properly configure your repository will adversely impact your grade.
The readings for Tuesday, August 21 are
Optional: 6 Stages of Linux Boot Process (Startup Sequence), An introduction to the Linux boot and startup processes, and Kernel Boot Process
Consider doing the Learning Git Branching tutorial if you are not familiar with branching.
Note: Don't worry if you don't get the readings done by Tuesday, as this is the first week of class.
Once you have done the readings, answer the following Reading 00 Quiz questions:
To submit your answers, you will need create a answers.json
or
answers.yaml
file in the reading00
folder of your assignments
repository:
For this class, you must use a separate git branch for each assignment. This means that the work for each reading and challenge must be done in a separate branch. To create and checkout a new branch, you can do the following:
$ git checkout master # Make sure we are in master branch
$ git pull --rebase # Make sure we are up-to-date with GitLab repository
$ git checkout -b reading00 # Create reading00 branch and check it out
Once you do the above, you should see the following output for the git-branch command:
$ git branch
master
* reading00
The *
indicates that we are currently on the reading00
branch.
You can either hand-write the answers
file using your favorite text
editor or you can use the online form to generate the JSON data.
A hand-written answers.yaml
may look like the following:
q1: [telemetry]
q2:
- scalability
- processor
- mouse
- keyboard
q3:
- functions
- call
- awesome
- lame
q4: toomanythreads
q5:
- iOS
- monitoring
- iphones
- NSA
q6: [init, bios, kernel, bootloader, mbr]
The equivalent answers.json
generated using the online form may look
like the following:
{
"q1": "telemetry",
"q2": [
"scalability",
"processor",
"mouse",
"keyboard"
],
"q3": [
"functions",
"call",
"awesome",
"lame"
],
"q4": "toomanythreads",
"q5": [
"iOS",
"monitoring",
"iphones",
"NSA"
],
"q6": [
"init",
"bios",
"kernel",
"bootloader",
"mbr"
]
}
You may use either format. To determine which symbols correspond to which response, take a look at the Reading 00 Quiz file.
To check your answers, you can use the provided .scripts/submit.py
script:
$ cd reading00 # Go into reading00 folder
$ $EDITOR answers.json # Edit your answers.json file
$ ../.scripts/submit.py # Submit reading00
Submitting reading00 assignment ...
Submitting reading00 quiz ...
Q1 0.00
Q2 0.12
Q3 0.00
Q4 0.00
Q5 0.00
Q6 0.10
Score 0.23
This script will submit your reading00/answers.json
file to dredd,
which is the automated grading system. dredd will take your answers
and return to you a score as shown above. Each reading is worth
3.0 points.
Note: You may submit your quiz answers as many times as you want; dredd does not keep track of who submits what or how many times. It simply returns a score.
Once you have your answers file, you need to add, commit the file, and push your commits to GitLab:
$ git add answers.json # Add answers.json to staging area
$ git commit -m "Reading 00: Done" # Commit work
$ git push -u origin reading00 # Push branch to GitLab
Note: You may edit and commit changes to your branch as many times
as you wish. Just make sure all of your work goes in the appropriate
branch and then perform a git push
when you are done.
When you are ready for your final submission, you need to create a merge request via the GitLab interface:
First, go to your repository's Branches page and then press the Merge Request button for the appropriate branch:
Next, click on the "Change branches" link so you can set the Target branch to your own repository (rather than the class repository).
Failure to select your own repository will lead to you unintentionally sharing your answers to the class, so please make sure you select your repository and not the class one.
Finally, assign the merge request to the appropriate TA (reference the Reading 00 TA List) and submit the merge request.
Every commit on GitLab will automatically submit your quiz or code to dredd and the results of each run is displayed in the merge request as a Pipeline task. To view the results of the submission, click on the Pipeline number and then the test button. You should then be able to see the results of the automated test, which should look something like this:
Once you have made the merge request, the TA can verify your work and provide feedback via the discussion form inside the merge request. If necessary, you can update your submission by simply commit and pushing to the appropriate branch; the merge request will automatically be updated to match your latest work.
When all work is complete, the TA will merge your branch and close the merge request.
Please do not accept or close your own merge requests. Doing so will confuse the graders, who use the list of open merge requests to know who to grade.