xref: /xv6-public/Notes (revision f9bc4452)
1bochs 2.2.6:
2./configure --enable-smp --enable-disasm --enable-debugger --enable-all-optimizations --enable-4meg-pages --enable-global-pages --enable-pae --disable-reset-on-triple-fault
3bochs CVS after 2.2.6:
4./configure --enable-smp --enable-disasm --enable-debugger --enable-all-optimizations --enable-4meg-pages --enable-global-pages --enable-pae
5
6bootmain.c doesn't work right if the ELF sections aren't
7sector-aligned. so you can't use ld -N. and the sections may also need
8to be non-zero length, only really matters for tiny "kernels".
9
10kernel loaded at 1 megabyte. stack same place that bootasm.S left it.
11
12kinit() should find real mem size
13  and rescue useable memory below 1 meg
14
15no paging, no use of page table hardware, just segments
16
17no user area: no magic kernel stack mapping
18  so no copying of kernel stack during fork
19  though there is a kernel stack page for each process
20
21no kernel malloc(), just kalloc() for user core
22
23user pointers aren't valid in the kernel
24
25are interrupts turned on in the kernel? yes.
26
27pass curproc explicitly, or implicit from cpu #?
28  e.g. argument to newproc()?
29  hmm, you need a global curproc[cpu] for trap() &c
30
31no stack expansion
32
33test running out of memory, process slots
34
35we can't really use a separate stack segment, since stack addresses
36need to work correctly as ordinary pointers. the same may be true of
37data vs text. how can we have a gap between data and stack, so that
38both can grow, without committing 4GB of physical memory? does this
39mean we need paging?
40
41perhaps have fixed-size stack, put it in the data segment?
42
43oops, if kernel stack is in contiguous user phys mem, then moving
44users' memory (e.g. to expand it) will wreck any pointers into the
45kernel stack.
46
47do we need to set fs and gs? so user processes can't abuse them?
48
49setupsegs() may modify current segment table, is that legal?
50
51trap() ought to lgdt on return, since currently only done in swtch()
52
53protect hardware interrupt vectors from user INT instructions?
54
55test out-of-fd cases for creating pipe.
56test pipe reader closes then write
57test two readers, two writers.
58test children being inherited by grandparent &c
59
60some sleep()s should be interruptible by kill()
61
62locks
63  init_lock
64    sequences CPU startup
65  proc_table_lock
66    also protects next_pid
67  per-fd lock *just* protects count read-modify-write
68    also maybe freeness?
69  memory allocator
70  printf
71
72in general, the table locks protect both free-ness and
73  public variables of table elements
74  in many cases you can use table elements w/o a lock
75  e.g. if you are the process, or you are using an fd
76
77lock order
78  per-pipe lock
79  proc_table_lock fd_table_lock kalloc_lock
80  console_lock
81
82do you have to be holding the mutex in order to call wakeup()? yes
83
84device interrupts don't clear FL_IF
85  so a recursive timer interrupt is possible
86
87what does inode->busy mean?
88  might be held across disk reads
89  no-one is allowed to do anything to the inode
90  protected by inode_table_lock
91inode->count counts in-memory pointers to the struct
92  prevents inode[] element from being re-used
93  protected by inode_table_lock
94
95blocks and inodes have ad-hoc sleep-locks
96  provide a single mechanism?
97
98kalloc() can return 0; do callers handle this right?
99
100test: one process unlinks a file while another links to it
101test: one process opens a file while another deletes it
102test: deadlock d/.. vs ../d, two processes.
103test: dup() shared fd->off
104test: does echo foo > x truncate x?
105
106sh: ioredirection incorrect now we have pipes
107sh: chain of pipes won't work, also ugly that parent closes fdarray entries too
108sh: dynamic memory allocation?
109sh: should sh support ; () &
110sh: stop stdin on ctrl-d (for cat > y)
111
112really should have bdwrite() for file content
113  and make some inode updates async
114  so soft updates make sense
115
116disk scheduling
117echo foo > bar should truncate bar
118  so O_CREATE should not truncate
119  but O_TRUNC should
120
121make it work on a real machine
122release before acquire at end of sleep?
123check 2nd disk (i.e. if not in .bochsrc)
124