5 - Lots of groups only tried combining the 3 group members' parts
6 only in the last few hours. Emphasize that this is a bad choice.
7 Encourage them to use CVS/sourceforge/etc.
9 - Encourage students to turn off -O3, or perhaps entirely turn off
10 optimization in provided makefiles?
12 - Suggest where to start in each assignment?
18 - Many students thought this was by far the hardest. What can we do
19 to make it a little easier?
21 - Students don't understand that they'll need to read lots of code
22 before they can start writing.
24 - Students don't read the debugging documentation. Point out in
25 multiple places, and especially point to the backtrace
28 - Students think data structures are more important than they really
29 are. Say that clever data structures won't get you too much extra
30 credit compared to simpler ones. Really bad or "stupid" data
31 structures might cost points though.
33 - Some students would appreciate more discussion of nitty-gritty
36 Finally, by doing pintos, an x86 OS, I was hoping to gain some
37 knowledge about how an X86 OS really works. Instead we ended up
38 banging on a black box with magical ASM that would pop up in gdb
39 when we had memory corruption. While one could make the argument
40 that this is too much application over theory, I feel like the
41 theory of OS/140 is application oriented enough that going over
42 what an x86 OS really does would not be harmful or
43 unacademic. What's in those first few bytes to bootstrap the OS?
44 How does it find a kernel that is scattered across a filesystem
45 that the bootloader/computer knows nothing about. How does I/O
46 initiailization works? What is that magic about transforming a
47 thread into a process? I have absolutely no idea.
49 This feeling of not having a better grasp of OS/low-level
50 programming is something I can't shake, but that I'm not sure how
51 one would be rectified. How on earth did pintos get written in ~2
52 months? I'm again at a loss.
54 - printf()s can fail in weird circumstances. Should we try adding
55 code for using the special output port, which doesn't need any
60 - Students thought project 2 was especially easy. Reduce amount of
61 time to allow more time for another project?
65 - One student suggestion:
67 Second point of confusion: the difference between kernel address
68 space and actual physical addresses (kernel address minus
69 PHYS_BASE). It seemed weird that the functions to access
70 pagedir entries used kernel virtual addresses instead of
71 physical addresses. We eventually realized that when the
72 assignment refers to the virtual-to-physical translations that
73 we're supposed to do, 'physical' actually means 'kernel virtual'
74 (or a location on disk). A sentence or two clearing up this
75 ambiguity would have been helpful.
79 - A fair number of students thought this was the hardest project.
80 Perhaps we could add some notes about where to start?
85 3) This is probably an "unsupported" configuration, however I'll point
86 it out anyway. Running user programs under Pintos compiled on my
87 desktop I get the following warning:
89 unknown ELF segment type 65041580
91 If you look at /usr/include/elf.h you will find:
93 #define PT_LOOS 0x60000000 /* Start of OS-specific */
95 It would appear that elf segments starting with this program header
96 are "OS-specific" My Occam's Razor explanation here is that the
97 segment holds the bits to configure the stack protection features in
100 gcc version is: gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1,
101 ssp-3.3.2-2, pie-8.7.6)
103 This probably means that we should provide a linker script that leaves