Syllabus: CS585/CS685, Linux Internals

Logistics

This class meets MWF 2:00 ‒ 2:50 in FPAT 255.

The instructor is Raphael Finkel, raphael@cs.uky.edu. The course web page is http://www.cs.uky.edu/~raphael/courses/CS585.html. My office is Hardymon 230. Telephone: 257-3885 (Hardymon). Office hours: M 11:00p-12:30p, R 2:00p-3:30p.

Topics

Each CS 585 is a specialty topic in computer science. This semester the topic is Linux 4.4 source code.

We will cover, often in fine detail, issues of memory addressing, processes, interrupts and exceptions, kernel synchronization, timing measurements, memory management, the process address space, system calls, signals, process scheduling, the virtual filesystem, managing I/O devices, disk caches, accessing files, swapping, the ext2 and ext3 filesystems, networking, interprocess communication, and program execution.

Learning outcomes

  1. An ability to design, implement and evaluate a computer-based system, process, component, or program to meet desired needs, specifically, ability to understand how the Linux kernel meets its needs.
  2. An ability to use current techniques, skills, and tools necessary for computing practices, specifically, understanding how the Linux kernel employs tools such as synchronization mechanisms, hash tables, and object-oriented jump tables.
  3. An ability to apply design and development principles in the construction of software systems of varying complexity, in particular, ability to design modifications to the Linux kernel.

Requirements

The course will be fast-paced. You must read the material on your own and study the Linux source code in addition to participating in class discussions.

Programming assignments will let you measure and manipulate the Linux kernel, modifying algorithms and data structures and introducing new features. For this purpose, you may use the machines in the Multilab (http://www.cs.uky.edu/students/facilities/multilab) on the second floor of the Engineering Annex, or a virtual machine we will build for you, or your own computer. You will need to use a secure shell to contact our computers from elsewhere; you can use ssh from Unix or putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/) from Win32 machines, or NoMachine (http://www.nomachine.com) from any machine. We will be using user-mode Linux (UML) to test your kernels, so you need not be physically present at the console to reboot the machines to your own modified Linux.

Grading

Your programming assignments will count 50% of your grade. The midterm and final will together count for 50% of your grade; whichever test you do better on will count 30%, the other 20%.

Programming will be graded on an open-ended scale. Each assignment will have an advertised number of points. If you do the assignment with no mistakes, you will get that number of points; errors will detract from your total. You will be awarded no points on an assignment for which you earn fewer than half the advertised number of points. You cannot get more than 500 points. 400 points is an A; 300 points is a B. You are not graded on class attendance.

Our accreditation association and the policy of the Graduate School require that there be different assignments and grading criteria for undergraduate students and graduate students in 400G and 500-level courses. Undergraduate students need to get 350 points for an A, 250 for a B.

Schedule

The following is what I hope to cover. Our mileage will certainly vary.

 F
Jan 8  n   1  1
Jan 15  n   2  2
Jan 22  3   3  3a
Jan 29  4   4  4
Feb 5  5   5  5
Feb 12  6   6  6b
Feb 19  7   7  7
Feb 26  8   8  m
Mar 5  M   9  9c
Mar 12  n   n  n
Mar 19  9   10  10
Mar 26  11  11  11d
Apr 2  12  12  r
Apr 9  12  13  13
Apr 16  13  13  14e
Apr 23  14  14f 14
Apr 30   i
Code Meaning
1‒14 Chapters in Linux Kernel Development
Midterm exam (in class)
Discussion of midterm exam
Final: Monday April 30, 1p-3p.
No class - University holiday
No class - Religious holiday
abcde due dates for assignments
Final deadline

References

The two required texts for the course are

You might also be interested in:

Love's book is especially good at high-level details; Bovet and Cesati for low-level details.

Prerequisites

You must be familiar with C programming and with using Unix, in particular, text editing, compiling, and using the file system. You should have taken CS470 or equivalent.

Grading criteria

For programs, correctness is an important criterion, but is by no means the whole story. Grades on programs will be based on

Late penalty

You may do the assignments in this class in any order and at any rate. However, you may not turn in more than one assignment per week. You may submit a revised version of any assignment that you have already submitted unless we have started to grade your previous submission. The length of the grace period will depend on how busy we are; we make no guarantees. No assignment will be accepted after the start of class on Wednesday of the last week of instruction.

How to submit programs

Submit all work electronically. Completed assignments, including program, documentation, test data, and output, preferably in a single file (you may use shar, rar, zip, gzip, bzip2, or tar) as an attachment, should be mailed to raphael@cs.uky.edu. Don't send me your entire kernel! Send a patch file (see page 404 of Love's book).

Responsible use of computers

You are expected to use the computing facilities on campus in accordance with standards of honesty and personal conduct. Those standards, outlined in the University of Kentucky Policy governing access to and use of University of Kentucky computing resources , available at https://www.uky.edu/regs/sites/www.uky.edu.regs/files/files/ar/ar10-1.pdf, call for all members of the community to act in a responsible, ethical, and professional way. This note offers guidelines in applying those standards to use of these facilities.

The operating systems used by our facilities encourage sharing of information. Security mechanisms for protecting information from unintended access, from within the system or from the outside, are minimal. These mechanisms, by themselves, are not sufficient for a large community in which protection of individual privacy is as important as sharing. Users must supplement the system's security mechanisms by using the system in a manner that preserves the privacy of others.

Actions taken by users intentionally to interfere with or to alter the integrity of the system are out of bounds. Such actions include unauthorized use of accounts, impersonation of other individuals in communications, attempts to capture or crack passwords or encryption, and destruction or alteration of data or programs belonging to other users. Equally unacceptable are intentional efforts to restrict or deny access by legitimate users to the system.

Plagiarism

All academic work, written or otherwise, that you submit is expected to be the result of your own thought, research, or self-expression. You may certainly discuss the programs with each other, but you must not show each other your code; everyone must develop the code completely independently. It is a serious offense to allow other students to copy your work or to copy the work of other students (even if it is in a public computer file). If you borrow ideas, algorithms, wording, or code from other sources, you must acknowledge that fact or you have committed plagiarism. If you directly take more than about 4 words in a row from any source, you must indicate that you have done so, typically with a footnote or an inline citation, using indentation or quote marks to set off the quoted text. (Some of this text is taken from the EDP202 plagiarism guide.)  Offenses against this policy are punished quite strictly. The minimum punishment is an E grade that cannot be removed by the repeat option.