Fix image links.

charming_chatroom.md

@@ -44,7 +44,7 @@ Implement the provided function to use a TCP IPv4 connection and connect to the
 
 **Notice** the writing and reading to the server use `write_all_to_socket()` and `read_all_from_socket()`.  You will have to implement these functions to handle the failures of read/write calls, but more on that later.
 
-The figure below gives you an idea about how the client side architecture looks like: ![Alt](/images/ClientArch.png "Title")
+The figure below gives you an idea about how the client side architecture looks like: ![Alt](/images/assignment-docs/lab/charming_chatroom/ClientArch.png "Title")
 
 So to sum up, your job in the client program is:
 
@@ -65,7 +65,7 @@ So to sum up, your job in the client program is:
 * port - The port number to accept connections on.
 
 Similar to `client.c`, a lot of the functionality in `server.c` has been implemented for you.  Your job is to set up the server to use TCP IPv4 with reusable ports and gracefully close the server when `SIGINT` is received.
- The figure below illustrates how a message propagates through the system: ![Alt](/images/MessageBroadcast.png "Title")
+ The figure below illustrates how a message propagates through the system: ![Alt](/images/assignment-docs/lab/charming_chatroom/MessageBroadcast.png "Title")
 
 To sum up, you have to:
 
@@ -75,7 +75,7 @@ To sum up, you have to:
 
 Here is the overall client-server architecture:
 
-![Alt](/images/OverallArchitecture.png "Title")
+![Alt](/images/assignment-docs/lab/charming_chatroom/OverallArchitecture.png "Title")
 
 ## Read/Write Failures
 

extreme_edge_cases.md

@@ -98,7 +98,7 @@ camelCaser takes in a C string, which represents an arbitrary number of sentence
 
 For those who like pictures, here is what the return value of camelCaser looks like in memory:
 
-![Memory Map](/images/char_double_pointer.jpg)
+![Memory Map](/images/assignment-docs/mp/finding_filesystems/char_double_pointer.jpg)
 
 In the above picture, you can see that we have a `char` double pointer called 'array'. In this scenario, the `char` double pointer points to the beginning of a NULL-terminated array of character pointers. Each of the character pointers in the array points to the beginning of a NULL-terminated `char` array that can be anywhere in memory.
 

finding_filesystems.md

@@ -98,7 +98,7 @@ typedef struct {
 
 ```
 
-![Finding Map](http://cs241.cs.illinois.edu/images/map.png)
+![Finding Map](http://cs241.cs.illinois.edu/images/assignment-docs/mp/finding_filesystems/map.png)
 
 The `file_system` struct keeps track of the metadata, the root inode (where `fs->inode_root[0]` is the root `"/"` inode), and the root of the `data_block`s.
 

ideal_indirection.md

@@ -34,7 +34,7 @@ The actual layout is taken directly from a real 32 bit processor and operating s
 
 For illustrative purposes a Page Table Entry looks like the following:
 
-![Page Table Entry](/images/page_table_entry.png)
+![Page Table Entry](/images/assignment-docs/lab/ideal_indirection/page_table_entry.png)
 
 Each entry is represented as a struct with bit fields whose syntax you can learn about in a [tutorial](http://www.tutorialspoint.com/cprogramming/c_bit_fields.htm).
 The bit fields basically allows us to squeeze multiple flags into a single 32 bit integer.
@@ -156,7 +156,7 @@ For this lab we have 2 levels of indirection (see `page_table.h`).
 
 The following illustration demonstrates how to translate from a virtual address to a physical address:
 
-![Virtual Address Translation](/images/virtual_address_translation.png)
+![Virtual Address Translation](/images/assignment-docs/lab/ideal_indirection/virtual_address_translation.png)
 
 That this image is saying is that you are to take the top 10 bits of the provided virtual address to index an entry in the page directory of the process.
 That entry should contain the base address of a page table.

lovable_linux.md

@@ -85,7 +85,7 @@ unused pages to not present as well. In this layout everything in Kernel
 the first 4MB, that isn’t the page for video memory, should be
 marked not present.
 
-![Page Initialization](/images/391/initialize_paging.png)
+![Page Initialization](/images/assignment-docs/lab/lovable_linux/initialize_paging.png)
 
 Make sure that you align your pages (page directory and page 8 MB
 tables) on 4 kB boundaries. To align things in x86:
@@ -319,7 +319,7 @@ blocks. The first block is called the boot block, and holds both file system sta
 the statistics and each directory entry occupy 64B, so the file system can hold up to 63 files. The first directory entry
 always refers to the directory itself, and is named ".", so it can really hold only 62 files.
 
-![Filesystem Layout](/images/391/fs_layout.png)
+![Filesystem Layout](/images/assignment-docs/lab/lovable_linux/fs_layout.png)
 
 Each directory entry gives a name (up to 32 characters, zero-padded, but not necessarily including a terminal EOS
 or O-byte), a file type, and an index node number for the file. File types are 0 for a file giving user-level access to
@@ -366,7 +366,7 @@ system call should update this member.
 
 4. A "flags" member for, among other things, marking this file descriptor as "in-use."
 
-![File Descriptor Table](/images/391/file_description_table.png)
+![File Descriptor Table](/images/assignment-docs/lab/lovable_linux/file_description_table.png)
 
 When a process is started, the kernel should automatically open stdin and stdout, which correspond to file descriptors O and 1, respectively. stdin is a read-only file which corresponds to keyboard input. stdout is a write-only
 file corresponding to terminal output. “Opening” these files consists of storing appropriate jump tables in these two
@@ -470,7 +470,7 @@ The virtual memory map for each task is show in the figure.
 The kernel is loaded at physical address 0x400000 (4 MB), 128MB and also mapped at virtual address 4 MB.
 A global page directory entry with its Supervisor bit set should be set up to map the kernel to virtual address ox400000 (4 MB). This ensures that the kernel, which is linked to run with its starting address at 4 MB, will continue to work even after paging is turned on.
 
-![Memory Mapping](/images/391/memory_map.png)
+![Memory Mapping](/images/assignment-docs/lab/lovable_linux/memory_map.png)
 
 To make physical memory management easy, you may assume there is at least 16 MB of physical memory on the system.
 Then, use the following (static) strategy: the first user-level program (the shell) should be loaded at physical 8 MB, and the second user-level program, when it is executed by the shell, should be loaded at physical 12 MB. The program image itself is linked to execute at virtual address 0x08048000.
@@ -509,7 +509,7 @@ segment descriptor. When the x86 sees that a new CS is specified, it will perfor
 for the IDT entry will run in the new privilege level. This way, the system call interface is accessible to user space but
 the code executes in the kernel.
 
-![Interrupt Gate](/images/391/interrupt_gate.png)
+![Interrupt Gate](/images/assignment-docs/lab/lovable_linux/interrupt_gate.png)
 
 ## Appendix E: Stack Switching and the TSS
 The last detail of user space to kernel transitions on system calls, interrupts, or exceptions is stack switching. The stack
@@ -584,7 +584,7 @@ to user space. Be sure you don’t clobber the user’s EAX value from its hardw
 From `sigreturn` - have `sigreturn` return the hardware context’s EAX value so that you won’t have to special-case
 the return from `sigreturn`.
 
-![Signals Figures](/images/391/signals_figures.png)
+![Signals Figures](/images/assignment-docs/lab/lovable_linux/signals_figures.png)
 
 Shown in Figure 2 is a slightly-modified version of the struct pt_regs structure that Linux uses for its hardware
 context; this modified structure is what you should use in this MP. The “Error Code / Dummy” field has been added to

mad_mad_access_pattern.md

@@ -82,7 +82,7 @@ if (node->right_child) {
 }
 ```
 
-![BTRE](/images/241_memory_mapped_madness_diagram.png)
+![BTRE](/images/assignment-docs/lab/mad_mad_access_patterns/241_memory_mapped_madness_diagram.png)
 
 Note that none of the binary search trees we give you will have duplicate keys.
 

mini_valgrind.md

@@ -22,7 +22,7 @@ The main concept of this lab is that we can track each block of memory using som
 
 Here's an illustration:
 
-![meta_data_linked_list](/images/mini_valgrind.jpg)
+![meta_data_linked_list](/images/assignment-docs/lab/mini_valgrind/mini_valgrind.jpg)
 
 When the program is about to exit, we can look at this metadata list to see what the user hasn't freed. These are your memory leaks.
 

networking_mp.md

@@ -219,7 +219,7 @@ One way to reason about connections in a nonblocking server is to visualize each
 
 A suggested flowchart for the server automata:
 
-![Server Flowchart](/images/networking_server_flowchart.png)
+![Server Flowchart](/images/assignment-docs/mp/nonstop_networking/networking_server_flowchart.png)
 
 ### Maintaining persistent connection state
 

parallel_make.md

@@ -53,7 +53,7 @@ Here is an example Makefile:
 
 The following graph represents the above Makefile. Note that 'a' and 'b' form a cycle (-> 'b' -> 'a' ->). 
 
-![Makefile Graph](../images/ColorfulDeadlock.svg)
+![Makefile Graph](../images/assignment-docs/mp/parallel_make/ColorfulDeadlock.svg)
 
 Some more resources on RAGs & Deadlock: [Wikipedia](https://en.wikipedia.org/wiki/Deadlock), [Coursebook](http://cs241.cs.illinois.edu/coursebook/Deadlock#resource-allocation-graphs).
 
@@ -240,7 +240,7 @@ You can use `system()` to run the commands associated with each rule. There are
 
 For your convenience these rules are captured in the following flow chart:
 
-![Flow Chart](../images/parmake_flowchart.svg)
+![Flow Chart](../images/assignment-docs/parallel_make/parmake_flowchart.svg)
 
 ## Parallelize! (Part 2 Only)