chapter/software-stack: Restructure repo according to updated methodo…

…logy

- Move all content to the `chapers/` folder
- Separate between `reading/`, `guides/`, `drills/` etc.
- Modify `config.yaml` to reflect the changes above
- Update `labeler.yml` to the new structure
- Fix broken links and paths
- Copy the generic `slides.mk` into `chapters/software-stack/Makefile` to
make the chapter more self-contained

Signed-off-by: Teodor Dutu <[email protected]>

.github/labeler.yml

@@ -1,5 +1,5 @@
 topic/software-stack:
-  - 'content/chapters/software-stack/**/*'
+  - 'chapters/software-stack/**/*'
 
 topic/data:
   - 'content/chapters/data/**/*'
@@ -16,6 +16,34 @@ topic/app-interact:
 topic/general:
   - 'chapters/general/**/*'
 
+area/reading:
+  - '**/reading/*'
+  - '**/reading/**/*'
+
+area/media:
+  - '**/media/*'
+  - '**/media/**/*'
+
+area/slides:
+  - '**/slides/*'
+  - '**/slides/**/*'
+
+area/guides:
+  - '**/guides/*'
+  - '**/guides/**/*'
+
+area/tasks:
+  - '**/tasks/*'
+  - '**/tasks/**/*'
+
+area/questions:
+  - '**/questions/*'
+  - '**/questions/**/*'
+
+area/projects:
+  - '**/projects/*'
+  - '**/projects/**/*'
+
 area/quiz:
   - '**/quiz/*'
 
@@ -32,8 +60,15 @@ area/code:
 
 area/infra:
   - 'util/**/*'
+  - 'common/*'
+  - 'common/**/*'
+  - 'scripts/*'
+  - 'scripts/**/*'
+  - '.github/*'
   - '.github/**/*'
   - 'Dockerfile'
+  - 'Makefile'
+  - 'config.yaml'
 
 area/assignment:
   - 'content/assignments/**/*'

chapters/software-stack/Makefile

@@ -0,0 +1,33 @@
+RVMD = reveal-md
+MDPP = markdown-pp
+FFMPEG = ffmpeg
+
+SLIDES ?= slides.mdpp
+SLIDES_OUT ?= slides.md
+MEDIA_DIR ?= media
+SITE ?= _site
+OPEN ?= xdg-open
+
+.PHONY: all html clean videos
+
+all: videos html
+
+html: $(SITE)
+
+$(SITE): $(SLIDES)
+	$(MDPP) $< -o $(SLIDES_OUT)
+	$(RVMD) $(SLIDES_OUT) --static $@
+
+videos:
+	for TARGET in $(TARGETS); do \
+		$(FFMPEG) -framerate 0.5 -f image2 -y \
+			-i "$(MEDIA_DIR)/$$TARGET/$$TARGET-%d.svg" -vf format=yuv420p $(MEDIA_DIR)/$$TARGET-generated.gif; \
+	done
+
+open: $(SITE)
+	$(OPEN) $</index.html
+
+clean:
+	-rm -f $(MEDIA_DIR)/*-generated.gif
+	-rm -f *~
+	-rm -fr $(SITE) $(SLIDES_OUT)

chapters/software-stack/applications/drills/tasks/app-investigation/README.md

@@ -0,0 +1,21 @@
+# App Investigation
+
+Enter the `app-investigation/support/` folder and go through the practice items below.
+Select a binary executable application and a scripted application.
+
+1. Use `ldd` on the two applications.
+   Notice the resulting messages and explain the results.
+
+1. Use `ltrace` and `strace` on the two applications.
+   Follow the library calls and the system calls done by each application.
+
+1. Check to see whether there are statically-linked application executables in the system.
+   The `file` command tells if the file passed as argument is a statically-linked executable.
+   If you can't find one, install the `busybox-static` package.
+
+1. Look into what [busybox](https://busybox.net/) is and explain why it's custom to have it as statically-linked executable.
+
+1. Run `ldd`, `nm`, `strace`, `ltrace` on a statically-linked application executable.
+   Explain the results.
+
+If you're having difficulties solving this exercise, go through [this](../../../reading/app-investigate.md) reading material.

content/chapters/software-stack/lab/content/app-investigate.md → chapters/software-stack/applications/reading/app-investigate.md

@@ -3,10 +3,10 @@
 Let's spend some time investigating actual applications residing on the local system.
 For now, we know that applications are developed using high-level languages and then compiled or interpreted to use the lower-layer interfaces of the software stack, such as the system call API.
 
-Let's enter the `support/app-investigate/` folder and run the `get_app_types.sh` script:
+Let's enter the `app-investigation/support/` folder and run the `get_app_types.sh` script:
 
 ```console
-student@os:~/.../lab/support/app-investigate$ ./get_app_types.sh
+student@os:~/.../tasks/app-investigation/support/$ ./get_app_types.sh
 binary apps: 2223
 Perl apps: 256
 Shell apps: 454
@@ -20,7 +20,7 @@ The output will differ between systems, given each has particular types of appli
 We list them by running the command inside the `get_app_types.sh` script:
 
 ```console
-student@os:~/.../lab/support/app-investigate$ find /usr/bin /bin /usr/sbin /sbin -type f -exec file {} \;
+student@os:~/.../tasks/app-investigation/support/$ find /usr/bin /bin /usr/sbin /sbin -type f -exec file {} \;
 [...]
 /usr/bin/qpdldecode: ELF 64-bit LSB shared object, x86-64 [...]
 /usr/bin/mimeopen: Perl script text executable
@@ -31,16 +31,5 @@ As above, the output will differ between systems.
 
 So, depending on the developers' choice, applications may be:
 
-* compiled into executables, from compiled languages such as C, C++, Go, Rust, D
-* developed as scripts, from interpreted languages such as Python, Perl, JavaScript
-
-## Practice
-
-Enter the `support/app-investigate/` folder and go through the practice items below.
-Select a binary executable application and a scripted application from those listed above.
-
-1. Use `ldd` on the two applications.
-   Notice the resulting messages and explain the results.
-
-1. Use `ltrace` and `strace` on the two applications.
-   Follow the library calls and the system calls done by each application.
+- compiled into executables, from compiled languages such as C, C++, Go, Rust, D
+- developed as scripts, from interpreted languages such as Python, Perl, JavaScript

chapters/software-stack/high-level-languages/drills/tasks/high-level-lang/README.md

@@ -0,0 +1,37 @@
+# High-Level Languages
+
+Enter the `high-level-lang/support/` folder and go through the practice items below.
+
+1. Use `make` to create the `hello` executable from the `hello.go` file (a Go "Hello, World!"-printing program).
+   Use `ltrace` and `strace` to compute the number of library calls and system calls.
+   Use `perf` to measure the running time.
+
+   Compare the values with those from the "Hello, World!"-printing programs in C and Python.
+
+1. Create a "Hello, World!"-printing program in a programming language of your choice (other than C, Python and Go).
+   Find the values above (library calls, system calls and running time).
+
+   [Quiz](../drills/questions/high-level-lang.md)
+
+1. Create programs in C, Python and Go that compute the N-th Fibonacci number.
+   `N` is passed as a command-line argument.
+
+   Use `ltrace` and `strace` to compute the number of library calls and system calls.
+   Use `perf` to measure the running time.
+
+   Compare the values of the three programs.
+
+1. Create programs in C, Python and Go that copy a source file into a destination file.
+   Both files are passed as the two command-line arguments for the program.
+   Sample run:
+
+   ```console
+   student@so:~$ cp src dest
+   ```
+
+   Use `ltrace` and `strace` to compute the number of library calls and system calls.
+   Use `perf` to measure the running time.
+   Use source files of different sizes.
+   Compare the outputs of these commands on the three programs.
+
+If you're having difficulties solving this exercise, go through [this](../../../reading/high-level-lang.md) reading material.

content/chapters/software-stack/lab/support/high-level-lang/hello.go → chapters/software-stack/high-level-languages/drills/tasks/high-level-lang/support/hello.go

@@ -3,5 +3,5 @@ package main
 import "fmt"
 
 func main() {
-	fmt.Println("Hello, World!");
+	fmt.Println("Hello, World!")
 }

content/chapters/software-stack/lab/content/high-level-lang.md → chapters/software-stack/high-level-languages/reading/high-level-lang.md

@@ -5,34 +5,34 @@ Still, for improved development time and safety, other programming languages can
 Most (if not all) of these high-level programming languages still make use of the standard C library.
 Such that a call to a function in Python would end-up making a call to a function in the standard C library.
 
-The `support/high-level-lang/` folder stores the implementation of a simple "Hello, World!"-printing program in Python.
+The `high-level-lang/support/` folder stores the implementation of a simple "Hello, World!"-printing program in Python.
 We simply invoke the `python` interpreter to run the program:
 
 ```console
-student@os:~/.../lab/support/high-level-lang$ python hello.py
+student@os:~/.../tasks/high-level-lang/support$ python hello.py
 Hello, world!
 ```
 
 We count the number of functions called from the standard C library and the number of system calls:
 
 ```console
-student@os:~/.../lab/support/high-level-lang$ ltrace -l 'libc*' python hello.py 2> libc.out
+student@os:~/.../tasks/high-level-lang/support$ ltrace -l 'libc*' python hello.py 2> libc.out
 Hello, world!
 
-student@os:~/.../lab/support/high-level-lang$ wc -l libc.out
+student@os:~/.../tasks/high-level-lang/support$ wc -l libc.out
 50469 out
 
-student@os:~/.../lab/support/high-level-lang$ strace python hello.py 2> syscall.out
+student@os:~/.../tasks/high-level-lang/support$ strace python hello.py 2> syscall.out
 Hello, world!
 
-student@os:~/.../lab/support/high-level-lang$ wc -l syscall.out
+student@os:~/.../tasks/high-level-lang/support$ wc -l syscall.out
 948 syscall.out
 ```
 
 The dynamic standard C library (`libc.so.6`) is a dependency of the Python interpreter (`/usr/bin/python3`):
 
 ```console
-student@os:~/.../lab/support/high-level-lang$ ldd /usr/bin/python3
+student@os:~/.../tasks/high-level-lang/support$ ldd /usr/bin/python3
 [...]
         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa6fd6d0000)
 [...]
@@ -46,7 +46,7 @@ Each new layer in the software stack simplifies development but adds overhead.
 We can use `perf` to compare the running time between the Python and a C "Hello, World!"-printing programs:
 
 ```console
-student@os:~/.../lab/support/high-level-lang$ sudo perf stat ../static-dynamic/hello
+student@os:~/.../tasks/high-level-lang/support$ sudo perf stat ../static-dynamic/hello
 Hello, World!
 
  Performance counter stats for '../static-dynamic/hello':
@@ -65,7 +65,7 @@ Hello, World!
        0.000872000 seconds user
        0.000000000 seconds sys
 
-student@os:~/.../lab/support/high-level-lang$ sudo perf stat python hello.py
+student@os:~/.../tasks/high-level-lang/support$ sudo perf stat python hello.py
 Hello, world!
 
  Performance counter stats for 'python hello.py':
@@ -91,18 +91,3 @@ The Python code takes `69` milliseconds, whereas the C code runs in less than `1
 When deciding what programming language and what libraries and software components to use, you have to balance requirements for fast development and increased safety (inherent to higher-level programming languages) with requirements for speed or efficiency (common to lower-level programming languages such as C).
 Newer modern programming languages such as Go, Rust, D aim to add the benefits of high-level programming languages and keep efficiency close to the C programming language.
 Generally, additional software layers (libraries, language environments, interpreters) simplify development but decrease speed and efficiency.
-
-## Practice
-
-Enter the `support/high-level-lang/` folder and go through the practice items below.
-
-1. Use `make` to create the `hello` executable from the `hello.go` file (a Go "Hello, World!"-printing program).
-   Use `ltrace` and `strace` to compute the number of library calls and system calls.
-   Use `perf` to measure the running time.
-
-   Compare the values with those from the "Hello, World!"-printing programs in C and Python.
-
-1. Create a "Hello, World!"-printing program in a programming language of your choice (other than C, Python and Go).
-   Find the values above (library calls, system calls and running time).
-
-[Quiz](../quiz/high-level-lang.md)

chapters/software-stack/libc/drills/questions/malloc.md

@@ -0,0 +1,21 @@
+# `malloc()`
+
+## Question Text
+
+What system calls are invoked by the `malloc()` library call for Linux libc? (choose 2 answers)
+
+## Question Answers
+
++ `brk`
+
+- `free`
+
+- `dup`
+
++ `mmap`
+
+- `copy`
+
+## Feedback
+
+Depending on the allocation size, `malloc()` invokes `brk` or `mmap`.

chapters/software-stack/libc/drills/questions/printf-syscall.md

@@ -0,0 +1,19 @@
+# printf() System Call
+
+## Question Text
+
+What system call does the `printf()` function invoke?
+
+## Question Answers
+
+- `read`
+
++ `write`
+
+- `exec`
+
+- `exit`
+
+## Feedback
+
+`printf()` invokes the `write` system call to print messages to standard output.

chapters/software-stack/libc/drills/questions/printf-vs-write.md

@@ -0,0 +1,22 @@
+# printf() vs write
+
+## Question Text
+
+What are features provided by `printf()` when compared to `write`? (choose 2 answers)
+
+## Question Answers
+
++ buffering
+
+- outputs to standard output
+
+- may write to file
+
++ does output formatting
+
+- can work with binary data
+
+## Feedback
+
+`printf()` can do buffering to reduce the number of system calls.
+Also, `printf()`, as it name suggests (the `f` suffix), does output formatting.

chapters/software-stack/libc/drills/questions/strcpy-syscall.md

@@ -0,0 +1,19 @@
+# strcpy() System Call
+
+## Question Text
+
+What system call does the `strcpy()` function invoke?
+
+## Question Answers
+
+- `cpy`
+
+- `touch`
+
+- `memcpy`
+
++ no system call
+
+## Feedback
+
+`strcpy()` doesn't invoke system calls, because it doesn't require any feature that is only provided by the operating system.

chapters/software-stack/libc/drills/questions/syscall-tool.md

@@ -0,0 +1,19 @@
+# Syscall Tool
+
+## Question Text
+
+Which of following is **not*- and advantage of using libc for programs?
+
+## Question Answers
+
+- increased portability
+
++ reduced executable size
+
+- richer set of features
+
+- easier development
+
+## Feedback
+
+When using libc, because we add a new software component, the size of the resulting executable increases.