Syllabus
Syllabus
Credits 4
Course description
Introduction to operating systems using UNIX as the case study. System calls and utilities,
fundamentals of processes and interprocess communication.
Prerequisites
CS 261 [C] and (CS 271 [C] or ECE 271 [C])
Communication
This course uses:
● Canvas to host static course content and the gradebook. (No canvas inbox, discussions, etc.)
● Gradescope for submitting/grading assignments
● Ed discussions for the online classroom environment, announcements, etc.
● Ed Chat for informal instant messaging (not used for "official" announcements, etc)
● MS Teams for office hours with TAs
● Email for private or personal matters, including grading results and concerns.
Learning resources
All course materials are freely available online or through the school library.
● Michael Kerrisk. The Linux Programming Interface: A Linux and UNIX System Programming
Handbook. 1st. USA: No Starch Press, 2010. ISBN: 159327220
● Jens Gustedt. Modern C. USA: Manning, 2019. ISBN: 9781617295812
● C99 standards (Freely available working draft ISO/IEC 9899:TC3) pdf wiki (recommended)
● POSIX.1-2008 pdf html (recommended)
Measurable student learning outcomes
Upon completion of this course, students should be able to:
1. Justify the need for a multi-programmed OS and explain the general structure of such
systems.
2. Select system calls for appropriate uses.
3. Compare and contrast the process and thread abstractions and select the correct
abstraction when needed.
4. Assess and solve possible issues related to concurrent execution.
5. Explain the file abstraction and system level I/O.
6. Compare and choose mechanisms for inter-process communication.
7. Write software by applying appropriate system programming principles and techniques.
Course content
Week Topic
Week 2 Introduction to C
Week 4 Processes I
Week 5 Processes II
Week 10 Rust and Safe System Programming (Optional Content; not on final)
Letter grade
A 93 - 100+
A- 90 - 92
B+ 87 - 89
B 83 - 86
B- 80 - 82
C+ 77 - 79
C 73 - 76
C- 70 - 72
D+ 67 - 69
D 63 - 66
D- 60 - 62
F 0 - 59
Rubrics
Each rubric item is graded on a pass/fail basis with no partial credit within an item. Rubric items may
list an example test or command, which is not intended to be interpreted as the exact test or
command used in grading, but only as an example to clarify the type of test that might be performed.
Unfinished/Incomplete/Draft work
Submissions that fail to compile receive no credit. Submissions that produce unspecified output
(debug statements, flourishes, greeting messages, extra whitespace, etc) may lose significant points
on rubric items and will not be regraded. Submissions that fail to produce specified output may
likewise fail rubric items and will not be regraded.
Unimplemented parts of assignments should be filled in with placeholder code so that your
submission fails gracefully (exit with error, silently ignore input, etc.) without crashing. Crashing may
result in significant point deductions.
General exceptions
We understand that learning from others and from examples can be immeasurably valuable, and we
want to support your learning and promote collaborative learning as much as possible, while also
taking a firm stance on academic dishonesty.
You may use (directly copy) any code from course documents, examples on os1 man pages, and
directly provided by instructional staff in your work. You may copy code from outside sources that are
general in nature and idiomatic. Idiomatic code is the widely agreed on "standard" way of performing
certain routine actions. Idiomatic code is rarely more than 2-3 statements and performs a single
discrete task that is generic, routine, and common to a variety of programs.
Some examples of idiomatic code would be:
● Calling a library function/system call and checking the return value for errors.
● Performing a looping read/write operation to flush a buffer.
● Checking the length of a formatted string, allocating memory for it, and then writing the
formatted string to the allocated buffer.
Examples of non-idiomatic code that would be considered plagiarism if copied, whole or in part:
● A string search and replace function.
● A function that parses a file path into its constituent path components.
● Anything that might be described as an "algorithm"
You may share useful resources, general programming advice, high-level/structural approaches to
assignments (no directly copied assignment code; edited minimal-working examples of bugs are
allowed), input/output examples, etc. with other students. This specifically does not authorize you to
copy any code directly from other students.
Consider that the course follows the same policy of most programming discussion and Q/A boards:
You may ask and answer questions, including snippets of code as necessary to illustrate a point or
question, but we are not here to do your homework for you.
Harassment
Everyone has the right to feel safe and respected in their workplace. This includes instructional staff.
Do not harass instructional staff. Examples of harassment include:
● Flooding, or transmitting a similar message over multiple channels or repeatedly in the same
channel.
● Engaging with a confrontational, overly demanding, argumentative, or hostile tone
● Repeated grading appeals that lack substance or effort (grade grubbing)
● Demands of a grade adjustment
● Public negative, hostile, or derogatory comments about the instructor or staff.
● Emotional/Trauma dumping (oversharing distressing personal information). We care about
you, but we are not trained therapists and we cannot provide this level of emotional support to
students. Share only what is necessary for us to complete our professional duties. We can
always ask for more information if we need it.
Stop and think before you send: Is this something you would feel comfortable receiving from several
dozen students on a daily basis? Would it be appropriate for them to do so?
Sanctions
First offenses will generally be given a warning. Repeat offenses may face sanctions including being
banned from any or all course communication channels. Especially serious violations will be reported
to the university without being given a warning.
Boilerplate
Academic Integrity
Integrity is a character-driven commitment to honesty, doing what is right, and guiding others to do
what is right. Oregon State University Ecampus students and faculty have a responsibility to act with
integrity in all of our educational work, and that integrity enables this community of learners to
interact in the spirit of trust, honesty, and fairness across the globe.
Academic misconduct, or violations of academic integrity, can fall into seven broad areas, including
but not limited to: cheating; plagiarism; falsification; assisting; tampering; multiple submissions of
work; and unauthorized recording and use.
It is important that you understand what student actions are defined as academic misconduct at
Oregon State University. The OSU Libraries offer a tutorial on academic misconduct, and you can
also refer to the OSU Student Code of Conduct and the Office of Student Conduct and Community
Standard’s website for more information. More importantly, if you are unsure if something will violate
our academic integrity policy, ask your professors, GTAs, academic advisors, or academic integrity
officers.
Academic Calendar
All students are subject to the registration and refund deadlines as stated in the Academic Calendar:
https://registrar.oregonstate.edu/osu-academic-calendar.
Ecampus students are always encouraged to discuss issues that impact your academic success with the
Ecampus Success Team. Email [email protected] to identify strategies and resources that
can support you in your educational goals.