Academics
  /  
Courses
  /  
Descriptions
COMP_SCI 446: Kernel and Other Low-level Software Development


VIEW ALL COURSE TIMES AND SESSIONS

Prerequisites

(COMP_SCI 213 or COMP_ENG 205) and (COMP_SCI 343 (OS) or COMP_ENG 361 (architecture) or COMP_ENG 366/466 (embedded systems)) or consent of Instructor.

Description

The development of low-level software such as drivers, kernels, hypervisors, run-times, system libraries, JITs, and firmware is very different from the development of applications. The goal of this class is to teach students how such development is done, both in terms of the modes of thinking needed to design, implement, debug, and optimize low-level software, and in terms of how to leverage representative, widely-used tools to do so. Some of the techniques the class covers are also used in the design and optimization of the performance-critical parts of applications. 

Each student will apply what they are learning  to an individual or small group low-level software development project. Ideally, each student would come to the class with their own low-level software development task in mind.

The general environment we will consider is the Linux kernel on 64-bit x86 using the GCC and related compiler toolchains and tools. Other environments may include a custom kernel, a hypervisor, and firmware. Projects in the class can involve other platforms. The student will see:

  • Features of the C language and special features of most C compilers that are designed to facilitate mapping of hardware interfaces to software constructs:  bitfields, unions, forced alignment, packing, atomic and synchronization primitives,  calling conventions, etc.
  • Techniques to take complete control over the machine when necessary, or to build constructs that are not simple functions or data structures: inline assembly, separate assembly, self-modifying code, etc.
  • Important attributes of code and data, such as position independence, relocatability, symbol/section inclusion, embedding, loaders, etc.
  • Custom linking to build images that are not simple executables: linker scripts, ELF, static and dynamic linking (especially within a kernel).
  • Hardware and related debugging methods: JTAG, SPI/I2C, PCI, QEMU, kgdb, scope, logic analyzer, etc.
  • Debugging concurrency.
  • The hardware environment: interrupts, concurrency, memory properties, state machines, the nature of hardware interfaces, hardware bugs, forced firmware (e.g. SMI), microcode, etc.
  • The kernel environment in general: monolithic kernels, microkernels, hypervisors, executives,  APIs versus ABIs versus kernel-internal interfaces, system calls, libc, etc.
  • An in-depth view of a specific kernel environment: Linux kernel, kernel modules, Kbuild, etc.
  • Why and when to distrust the compiler and other tools, or the hardware.

This course is intended for advanced CS and CE undergraduates and graduate students, particularly Ph.D.s. If you’re interested in this class, but not sure you have the background, please contact the instructor.

  • For CS undergraduates, this course counts towards the Project requirement. CE undergraduates can petition to have this course count within the Systems Software Area.

COURSE INSTRUCTOR: Prof. Peter Dinda

BOOKS:

  • D. Bovet and M. Cesati, Understanding the Linux Kernel, 3rd Edition, O’Reilly, 2005. (required)
  • J. Corbet, A. Rubii, G. Kroah-Hartman, Linux Device Drivers, 3rd Edition, O’Reilly, 2005.  (reference)
  • R. Love, Linux Kernel Development, 3rd Edition, Addison-Wesley, 2010. (reference)

The first two books may have 4th editions by the start of the class, if so, we will use the 4th editions.

SOFTWARE:

  • Linux kernel
  • Palacios hypervisor
  • Nautilus aerokernel
  • Coreboot firmware

and perhaps others.  

It will be useful if students have access to a virtual machine monitor on their hardware. The best choice for this is VMware.

GRADING:

  • 60 % Project (quarter-long)
  • 20 % Project documentation and presentation
  • 20 % In-class discussion

Students in the class will undertake significant development efforts within a kernel or other low-level codebase of their choice. These projects will ideally be something that students bring to the class as a matter of personal interest or. For example, a student might write a device driver for some new hardware. A project can be undertaken by a team whose size depends on the complexity of the project. Open source software needs (e.g., http://kernelnewbies.org/KernelProjects) could also be a source of educational and useful projects.