Before we get into the heavier assignments in this course, you should invest sometime into setting up a workflow and develop good coding habits.
Working on a VM can be preferable to working on your host machine (i.e. “bare-metal”). You can virtualize other operating systems to test your applications. You can work on potentially buggy/dangerous code without compromising your host machine.
In this class, we will often be “hacking” the Linux kernel and attempting to boot into those hacked kernels. We need to use VMs since not all of us have a Linux host machine. Even if we did, we wouldn’t want to ruin our host machines with our potentially buggy kernels.
We’ve already written a series of guides for working on your VM.
First and foremost, you should have a Debian VM installed already (see Debian VM Setup for a guide on how to do this).
You have more options than simply working on the VM’s graphical interface, which often feels clunky.
The most common workflow involves SSHing into your VM, which we’ve written a guide for. This is a good option if you want to conserve processing power on your host machine and disable the VM’s graphical interface.
Alternatively, you can setup an IDE to SSH into your VM. One option is using Visual Studio Code, which we’ve written up some notes (below) on how to use. This is a nice alternative to command-line editors like vim/emacs if you’re not familiar with them.
If you do decide to work in a command-line environment, here are some tools we’ve used to streamline our workflow:
bat
: A better version of cat
(installation)grep
: Pattern-match files (learn how to effectively use regexs to improve
search results). Even better, ripgrep
.tmux
: Terminal multiplexer. (e.g. open 2 panes for vim, 1 for dmesg
, 1 for
running commands).Before getting into hw4/supermom, please read through one of our kernel developer
workflow guides. These explain how to set up either vim
or VSCode for kernel
development.
vim
additions/tricks to help you develop more
efficiently while working on the kernel assignments. Note that this guide is
only relevant if you intend to work on the command-line using vim
. One notable
mention here is cscope
. This is a kernel-source navigator that works directly
in your terminal/vim session. This is far more powerful than using grep
to
look for a symbol definition/use in the source-tree.If you don’t want to use cscope
, there’s an popular online kernel-source
navigator: bootlin. Note
that kernel version matters when you’re navigating code – be sure you select the
correct version.
Like bootlin, you can look for symbols in the kernel-source and look for
instances of where they are defined and used. However, bootlin doesn’t index all
symbols, so you might have better luck searching with cscope
.