Home Courses Articles Slides FAQ

Lecture 11 - 17 October 2023

Topics Covered:

FAQ for first patch of P1:

Q: What goes in the first patch?

A: From Joel’s 14 October 2023 post in Matrix:

We are asking you to do something a little bit weird, but I think this will clarify: You are asked to make changes to the Linux kernel to implement your syscall. Once you have tested these changes (or earlier to back them up), you make a commit containing the all of these local changes to Linux and then generate an email patch for this new commit. This is the .patch file we are referring to in the instructions. Then, you copy the .patch file from its original location to your (new) firstname_lastname directory in the P1 directory of the ILKD_assignments repo. The commit for the first patch of your homework submission will consist of adding this .patch file to your named directory.

Q: When I generate the .patch file for my first commit, and try to locally apply it, git am complains about whitespace errors! Is this OK?

A: Yes, as long as it is in the line above the git version that has the two dashes and space. This is an artifact of git format-patch. You are welcome to remove this extraneous space from the .patch file before making your first commit, however we will not penalize you if you leave it in.

Q: Why goes git format-patch have this behavior?

A: The upstream git source code prints the space here. Via extensive digging with git blame, we traced the origin of this behavior back to this commit from 2005:

$ curl https://github.com/git/git/commit/a004d3f70f1c074f2d9bd55e7a925ff5916ebbeb.patch
From a004d3f70f1c074f2d9bd55e7a925ff5916ebbeb Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Tue, 29 Nov 2005 13:51:27 -0800
Subject: [PATCH] format-patch: do not abuse 3-dash marker line.

Before GIT version at the end of output we used a 3-dash marker;
but 3-dash marker is special and should not be overused.
Instead, use "-- " which is a standard practice in e-mails to
signal the beginning of trailing garbage.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 git-format-patch.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-format-patch.sh b/git-format-patch.sh
index a26d46dba0b1f9..4cd38f34efd84e 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -239,7 +239,7 @@ Date: '"$ad"
 	git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
 	echo
 	git-diff-tree -p $diff_opts "$commit"
-	echo "---"
+	echo "-- "
 	echo "@@GIT_VERSION@@"
 
 	case "$mbox" in

Back then, git format-patch was still just a shell script. We speculate that the space was added to maintain compatibility with existing code containing the hardcoded expectation of three characters.

Everything is a file (in Linux)

This elegant design principle dates back to the beginning of (Unix) time, a.k.a. the 70s. However, this simple principle is an oversimplification - consider the existence of directories. In reality, the slogan “Everything is a file” is a convenient shorthand for the more accurate but less catchy notion that (almost) all resources available to a process on a Unix-like operating system can be referenced by a file descriptor.

We will continue to investigate this concept throughout the course, but today we focus on one example: /proc.

The process filesystem: /proc

Unlike some of the more esoteric resources that can be referred to by a file descriptor, the entries found in the /proc directory on any Linux system are in fact real files.

However, they are not entirely like other files: they are transient. That is to say, these files are not stored on any long-term storage media, e.g. a hard drive. These files don’t need long term storage because they provide access to information that only exists at runtime.

Instead of reading the directory structure and contents from a storage medium, the kernel creates the files in /proc at runtime and synthesizes their contents on demand.

Specifically, the kernel creates a directory for each running process on the system named after its pid. In addition, the kernel provides a “magic” symlink named self whose target depends on which process is looking. Any process that examines the symlink sees it resolve to the folder that corresponds to the calling process’s pid.

This directory contains information about running processes. For a complete list of the contents, refer to the kernel documentation and the manpage.

Unfortunately, /proc also contains many miscellaneous files that were added before the community developed /sys. They are still present to preserve backwards compatibility.

A /proctical example

In bash, $$ is a special variable that expands to the pid of the bash process.

For example:

	$ echo $$
	1337

This means we can use $$ when building a path to reference the /proc subdirectory corresponding to the running bash process. In P1, the systemcall used the get_task_comm kernel macro to find the name of the running program. /proc also provides userspace access to this information. Here is an example:

	$ cat /proc/$$/comm
	bash

We can also discover the absolute path of the executable invoked to start the process by traversing another “magic” symlink named exe:

	$ readlink /proc/$$/exe
	/usr/bin/bash

If we replace $$ with self, we are now referring to the child process the shell created by forking itself and execing the user command:

	$ cat /proc/self/comm
	cat

	$ readlink /proc/self/exe
	/usr/bin/readlink

Another useful entry in /proc for a given process is the fd directory, which contains magic symlinks to all file descriptors owned by the process:

	$ ls -l /proc/self/fd
	... 0 -> /dev/pts/0
	... 1 -> /dev/pts/0
	... 2 -> /dev/pts/0
	... 3 -> /proc/128523/fd

As expected, the first three entries are stdin, stdout, and stderr which are connected to our terminal. We can also see how the ls program opens its own subdirectory in /proc by following the “magic” /proc/self symlink.

Watch before next class