xv6

port of xv6 to x86-64
git clone http://frotz.net/git/xv6.git
Log | Files | Refs | README | LICENSE

Notes (4008B)


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