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 25setting up first process 26 we do want a process zero, as template 27 but not runnable 28 just set up return-from-trap frame on new kernel stack 29 fake user program that calls exec 30 31map text read-only? 32shared text? 33 34what's on the stack during a trap or sys call? 35 PUSHA before scheduler switch? for callee-saved registers. 36 segment contents? 37 what does iret need to get out of the kernel? 38 how does INT know what kernel stack to use? 39 40are interrupts turned on in the kernel? probably. 41 42per-cpu curproc 43one tss per process, or one per cpu? 44one segment array per cpu, or per process? 45 46pass curproc explicitly, or implicit from cpu #? 47 e.g. argument to newproc()? 48 hmm, you need a global curproc[cpu] for trap() &c 49 50test stack expansion 51test running out of memory, process slots 52 53we can't really use a separate stack segment, since stack addresses 54need to work correctly as ordinary pointers. the same may be true of 55data vs text. how can we have a gap between data and stack, so that 56both can grow, without committing 4GB of physical memory? does this 57mean we need paging? 58 59what's the simplest way to add the paging we need? 60 one page table, re-write it each time we leave the kernel? 61 page table per process? 62 probably need to use 0-0xffffffff segments, so that 63 both data and stack pointers always work 64 so is it now worth it to make a process's phys mem contiguous? 65 or could use segment limits and 4 meg pages? 66 but limits would prevent using stack pointers as data pointers 67 how to write-protect text? not important? 68 69perhaps have fixed-size stack, put it in the data segment? 70 71oops, if kernel stack is in contiguous user phys mem, then moving 72users' memory (e.g. to expand it) will wreck any pointers into the 73kernel stack. 74 75do we need to set fs and gs? so user processes can't abuse them? 76 77setupsegs() may modify current segment table, is that legal? 78 79trap() ought to lgdt on return, since currently only done in swtch() 80 81protect hardware interrupt vectors from user INT instructions? 82 83test out-of-fd cases for creating pipe. 84test pipe reader closes then write 85test two readers, two writers. 86test children being inherited by grandparent &c 87 88some sleep()s should be interruptible by kill() 89 90cli/sti in acquire/release should nest! 91 in case you acquire two locks 92 93what would need fixing if we got rid of kernel_lock? 94 console output 95 proc_exit() needs lock on proc *array* to deallocate 96 kill() needs lock on proc *array* 97 allocator's free list 98 global fd table (really free-ness) 99 sys_close() on fd table 100 fork on proc list, also next pid 101 hold lock until public slots in proc struct initialized 102 103locks 104 init_lock 105 sequences CPU startup 106 proc_table_lock 107 also protects next_pid 108 per-fd lock *just* protects count read-modify-write 109 also maybe freeness? 110 memory allocator 111 printf 112 113wakeup needs proc_table_lock 114 so we need recursive locks? 115 or you must hold the lock to call wakeup? 116 117in general, the table locks protect both free-ness and 118 public variables of table elements 119 in many cases you can use table elements w/o a lock 120 e.g. if you are the process, or you are using an fd 121 122lock code shouldn't call cprintf... 123 124nasty hack to allow locks before first process, 125 and to allow them in interrupts when curproc may be zero 126 127race between release and sleep in sys_wait() 128race between sys_exit waking up parent and setting state=ZOMBIE 129race in pipe code when full/empty 130 131lock order 132 per-pipe lock 133 proc_table_lock fd_table_lock kalloc_lock 134 console_lock 135 136condition variable + mutex that protects it 137 proc * (for wait()), proc_table_lock 138 pipe structure, pipe lock 139 140systematic way to test sleep races? 141 print something at the start of sleep? 142 143do you have to be holding the mutex in order to call wakeup()? 144 145device interrupts don't clear FL_IF 146 so a recursive timer interrupt is possible 147 148what does inode->busy mean? 149 might be held across disk reads 150 no-one is allowed to do anything to the inode 151 protected by inode_table_lock 152inode->count counts in-memory pointers to the struct 153 prevents inode[] element from being re-used 154 protected by inode_table_lock 155 156blocks and inodes have ad-hoc sleep-locks 157 provide a single mechanism? 158 159need to lock bufs in bio between bread and brelse 160 161test 14-character file names 162and file arguments longer than 14 163and directories longer than one sector 164 165kalloc() can return 0; do callers handle this right? 166