- Bobby Chen
- Rajath Subramanyam
- Yang Xu
- Fan Yang
- Nicholas Bachmann
- Alec Benzer
- Sarah Dong
- Cyrus Eduljee
- Will Hennessy
- Bhuwan Khattar
- Hyun Bin Lee
- Zitian Liu
- Sammy Rabkin
- Zhengqi Yang
- Xiaocheng Yuan
For all technical and class related questions, go to Piazza.
For personal questions only, email email@example.com.
There is no required textbook for CS 241.
Some useful textbooks include:
A computer needs an operating system to manage its resources and provide support for common functions such as accessing peripherals. There are two categories of "customers" that an operating system must support. The first category is the community of users. We have all used computers and you may recognize operating systems' functions such as creating folders (directories) and moving files around. These are examples of operating system support for users. User support is not the objective of this course. This course addresses operating system support for the second category of customers; namely, the programmers. Those are people who write code to execute on the computer. When you write a program, it may have to interact with physical hardware (memory, flash storage, screen, network, etc.). For example, you may want to get input from a keyboard or mouse, you may want to read some configuration file stored on disk, you may want to output data to a screen or printer, or you may want to access a remote server across a network. The operating system presents common interfaces for programmers to perform these functions. The operating system also provides useful abstractions such as "tasks" (also called processes), "threads", and "semaphores". You can make the computer multitask by calling the operating system interface for creating new tasks or new threads. You can make these tasks coordinate and synchronize by using operating system semaphores. You can tell the computer the order in which you want tasks to be executed, which is called a scheduling policy. Finally, you can manage computer memory by calling the operating system function for memory management. System programming refers to writing code that tasks advantage of operating system support for programmers. This course is designed to introduce you to system programming.
By the end of this course, you should be proficient at writing programs that take full advantage of operating system support. To be concrete, we need to fix an operating system and we need to choose a programming language for writing programs. We chose the C language running on a Linux/UNIX operating system (which implements the POSIX standard interface between the programmer and the OS). This pairing of C and UNIX/Linux is used heavily by software that must provide high performance and low-level control of the program's execution. Hence, this course introduces you to systems programming via the specific case of C over UNIX. By the end of the course you should be proficient with this programming environment and should be able to write non-trivial pieces of software from web server code to your own multiplayer Internet games. More specifically, after taking this course you should be able to accomplish the following:
After the grades are available, you have 1 week to request a regrade. If you believe you were not graded correctly, please help up by asking for regarding during that window. After 1 week, no more regrade requests will be honored.
We meet for lectures 11:00 - 11:50 am Monday, Wednesday and Friday in Room 1404 SC. Lectures cover important operating system concepts, and their implementation. It is the students' responsibility to read assigned materials. You are expected to attend lectures, and will be responsible for announcements made during lecture, as well as on the cs241 web page, and on Piazza.
There are multiple discussion sessions. You should sign up for one of the discussion sessions using Banner as soon as possible.
We will be using linux machines, running POSIX system programming interface, in labs in 1245 DCL, 1265 and 1275 DCL and in 0220/0222 SC (basement). You should make sure that you have accounts on the EWS machines to do your machine problem assignments. We recommend that you use a 64-bit EWS machine.
We run our autograders on linux.ews.illinois.edu, so even if you develop your code elsewhere, you should test your code on linux.ews.illinois.edu before submitting and at regular intervals while developing your code. While the desktop EWS machines run the same OS and same word size, slight differences have resulted in problems for buggy code in past semesters.
To access these machines from outside the university, please use CITES VPN client.
If you want to audit the course and don't have an account, please speak with the course staff. If you have other problems relating to the existence of your account, please email firstname.lastname@example.org.
Cheating is taken very seriously in CS 241. Be sure to understand the departmental honor code. Your work in this class must be your own. If students are found to have cheated (e.g., by copying or sharing answers during an examination or sharing code for the project), all involved will at receive grades of 0 for the first infraction and will be reported to the academic office, and may receive additional penalties such as a reduction of one letter grade in the final course grade. Further infractions will result in failure in the course and/or recommendation for dismissal from the university.
You are a respected individual in a community of collegiality and trust. We honor and believe your word. We trust what you say and will generally not ask for proof. However, with trust comes responsibility. Violation of trust will not be tolerated. In particular, acts not befitting this community such as cheating (e.g., collaboration on homeworks or exams that are not meant to be collaborative) fall in the category of violation of trust. Individuals who commit such acts will lose the privileges of trust and receive grade reductions as described above.
Your machine problems must be a result of individual work. You are responsible for protecting your work. In the past, we had cases of copying solutions from other students without their knowledge. To avoid having your work copied without your knowledge, refrain from leaving source code prints lying around the lab, protect your files, don't give your passwords to anyone, and enter your passwords in a way that cannot be seen by others. Do not leave a login session active on an unattended workstation. Use xlock on the EWS workstations if you must leave briefly, or use some similar measure (or log out!) in other labs; remember that it's a violation of the CSIL policy (and probably the other lab policies) to leave your workstation unattended for any extended period of time. Report suspicious behavior to the lab sitters or the TAs.