165 lines
5.3 KiB
Text
165 lines
5.3 KiB
Text
bochs 2.2.6:
|
|
./configure --enable-smp --enable-disasm --enable-debugger --enable-all-optimizations --enable-4meg-pages --enable-global-pages --enable-pae --disable-reset-on-triple-fault
|
|
bochs CVS after 2.2.6:
|
|
./configure --enable-smp --enable-disasm --enable-debugger --enable-all-optimizations --enable-4meg-pages --enable-global-pages --enable-pae
|
|
|
|
bootmain.c doesn't work right if the ELF sections aren't
|
|
sector-aligned. so you can't use ld -N. and the sections may also need
|
|
to be non-zero length, only really matters for tiny "kernels".
|
|
|
|
kernel loaded at 1 megabyte. stack same place that bootasm.S left it.
|
|
|
|
kinit() should find real mem size
|
|
and rescue useable memory below 1 meg
|
|
|
|
no paging, no use of page table hardware, just segments
|
|
|
|
no user area: no magic kernel stack mapping
|
|
so no copying of kernel stack during fork
|
|
though there is a kernel stack page for each process
|
|
|
|
no kernel malloc(), just kalloc() for user core
|
|
|
|
user pointers aren't valid in the kernel
|
|
|
|
setting up first process
|
|
we do want a process zero, as template
|
|
but not runnable
|
|
just set up return-from-trap frame on new kernel stack
|
|
fake user program that calls exec
|
|
|
|
map text read-only?
|
|
shared text?
|
|
|
|
what's on the stack during a trap or sys call?
|
|
PUSHA before scheduler switch? for callee-saved registers.
|
|
segment contents?
|
|
what does iret need to get out of the kernel?
|
|
how does INT know what kernel stack to use?
|
|
|
|
are interrupts turned on in the kernel? probably.
|
|
|
|
per-cpu curproc
|
|
one tss per process, or one per cpu?
|
|
one segment array per cpu, or per process?
|
|
|
|
pass curproc explicitly, or implicit from cpu #?
|
|
e.g. argument to newproc()?
|
|
hmm, you need a global curproc[cpu] for trap() &c
|
|
|
|
test stack expansion
|
|
test running out of memory, process slots
|
|
|
|
we can't really use a separate stack segment, since stack addresses
|
|
need to work correctly as ordinary pointers. the same may be true of
|
|
data vs text. how can we have a gap between data and stack, so that
|
|
both can grow, without committing 4GB of physical memory? does this
|
|
mean we need paging?
|
|
|
|
what's the simplest way to add the paging we need?
|
|
one page table, re-write it each time we leave the kernel?
|
|
page table per process?
|
|
probably need to use 0-0xffffffff segments, so that
|
|
both data and stack pointers always work
|
|
so is it now worth it to make a process's phys mem contiguous?
|
|
or could use segment limits and 4 meg pages?
|
|
but limits would prevent using stack pointers as data pointers
|
|
how to write-protect text? not important?
|
|
|
|
perhaps have fixed-size stack, put it in the data segment?
|
|
|
|
oops, if kernel stack is in contiguous user phys mem, then moving
|
|
users' memory (e.g. to expand it) will wreck any pointers into the
|
|
kernel stack.
|
|
|
|
do we need to set fs and gs? so user processes can't abuse them?
|
|
|
|
setupsegs() may modify current segment table, is that legal?
|
|
|
|
trap() ought to lgdt on return, since currently only done in swtch()
|
|
|
|
protect hardware interrupt vectors from user INT instructions?
|
|
|
|
test out-of-fd cases for creating pipe.
|
|
test pipe reader closes then write
|
|
test two readers, two writers.
|
|
test children being inherited by grandparent &c
|
|
|
|
some sleep()s should be interruptible by kill()
|
|
|
|
cli/sti in acquire/release should nest!
|
|
in case you acquire two locks
|
|
|
|
what would need fixing if we got rid of kernel_lock?
|
|
console output
|
|
proc_exit() needs lock on proc *array* to deallocate
|
|
kill() needs lock on proc *array*
|
|
allocator's free list
|
|
global fd table (really free-ness)
|
|
sys_close() on fd table
|
|
fork on proc list, also next pid
|
|
hold lock until public slots in proc struct initialized
|
|
|
|
locks
|
|
init_lock
|
|
sequences CPU startup
|
|
proc_table_lock
|
|
also protects next_pid
|
|
per-fd lock *just* protects count read-modify-write
|
|
also maybe freeness?
|
|
memory allocator
|
|
printf
|
|
|
|
wakeup needs proc_table_lock
|
|
so we need recursive locks?
|
|
or you must hold the lock to call wakeup?
|
|
|
|
in general, the table locks protect both free-ness and
|
|
public variables of table elements
|
|
in many cases you can use table elements w/o a lock
|
|
e.g. if you are the process, or you are using an fd
|
|
|
|
lock code shouldn't call cprintf...
|
|
|
|
nasty hack to allow locks before first process,
|
|
and to allow them in interrupts when curproc may be zero
|
|
|
|
race between release and sleep in sys_wait()
|
|
race between sys_exit waking up parent and setting state=ZOMBIE
|
|
race in pipe code when full/empty
|
|
|
|
lock order
|
|
per-pipe lock
|
|
proc_table_lock fd_table_lock kalloc_lock
|
|
console_lock
|
|
|
|
condition variable + mutex that protects it
|
|
proc * (for wait()), proc_table_lock
|
|
pipe structure, pipe lock
|
|
|
|
systematic way to test sleep races?
|
|
print something at the start of sleep?
|
|
|
|
do you have to be holding the mutex in order to call wakeup()?
|
|
|
|
device interrupts don't clear FL_IF
|
|
so a recursive timer interrupt is possible
|
|
|
|
what does inode->busy mean?
|
|
might be held across disk reads
|
|
no-one is allowed to do anything to the inode
|
|
protected by inode_table_lock
|
|
inode->count counts in-memory pointers to the struct
|
|
prevents inode[] element from being re-used
|
|
protected by inode_table_lock
|
|
|
|
blocks and inodes have ad-hoc sleep-locks
|
|
provide a single mechanism?
|
|
|
|
need to lock bufs in bio between bread and brelse
|
|
|
|
test 14-character file names
|
|
and file arguments longer than 14
|
|
and directories longer than one sector
|
|
|
|
kalloc() can return 0; do callers handle this right?
|