omegaphoenix/cheetos

OS implementation for Caltech CS124

cheetos's Issues

Remove TODOs in mysh.c

Design Reference

The first iteration of the game will have one row of stationary aliens.
If possible, have Alien, Shooter, and Bullet inherit from a common struct?
Feel free to rename variables!

Alien

• x (position of top left corner)
• y
• icon[icon_height][icon_width] (the characters to display)
• icon_height
• icon_width
• exists
• speed
• direction
• health

Shooter

• x
• y
• icon[icon_height][icon_width]
• icon_height
• icon_width
• health

Bullet

• x
• y
• icon[icon_height][icon_width]
• icon_height
• icon_width
• speed
• direction

Game (not sure if we need a struct; could just be global vars)

• shooter
• aliens[]
• bullets[]
• level
• grid[25][80]
• bg_color

System Call Bugs

Suspected memory issue causing failures in multi-recurse, multi-oom, and possibly syn-read on QEMU.
We should also consider refactoring the array of files to a linked list to conserve space.
Currently multiOomFix branch is also failing syn-write and exec-missing (hanging) on Bochs.
This could be due to not deleting threads right away (might want to refactor how we are synchronizing anyways - use 2 semaphores (additional one for changes in exit_status) instead of 1 semaphore).

VM Synchronization Bug

I think the bug that sometimes breaks the parallel tests which test eviction has to do with accessing a frame while it is being deleted.

Currently the tests are failing with exit(-1) because !user_vaddr(fault_addr) is true in the exception.c page_fault() handler. This is caused by a fault within the kernel code. The kernel code that is being called is fetch_data_to_frame(). Here is the backtrace right before it fails:

#0 page_fault (f=0xc0132e64) at ../../userprog/exception.c:149
#1 0xc0022817 in intr_handler (frame=0xc0132e64) at ../../threads/interrupt.c:330
#2 0xc0022a1f in intr_entry () at ../../threads/intr-stubs.S:37
#3 0xc0132e64 in ?? ()
#4 0xffffffff in ?? ()
#5 0x00000008 in ?? ()
#6 0x00000282 in ?? ()
#7 0xc0111000 in ?? ()
#8 0xc003024d in fetch_data_to_frame (page=page@entry=0xc0136b8c) at ../../vm/page.c:227
#9 0xc002c919 in page_fault (f=0xc0132fb0) at ../../userprog/exception.c:160
#10 0xc0022817 in intr_handler (frame=0xc0132fb0) at ../../threads/interrupt.c:330
#11 0xc0022a1f in intr_entry () at ../../threads/intr-stubs.S:37
#12 0xc0132fb0 in ?? ()
#13 0x08048141 in ?? ()

The line in page.c that it is failing on is provided below:
struct frame_table_entry *fte = get_frame();

Thread bug

pintos -f
Kernel PANIC at ../../threads/thread.c:356 in thread_yield(): assertion `!intr_context()' failed.
Temporary fix in #72
Should investigate to get to root of issue

Project 4

• Argument Passing Every user program will page fault immediately until argument passing is implemented.
• User memory access (see section 5.1.5 Accessing User Memory). All system calls need to read user memory. Few system calls need to write to user memory.
• System call infrastructure (see section 5.3.4 System Calls). Implement enough code to read the system call number from the user stack and dispatch to a handler based on it.
• The exit system call. Every user program that finishes in the normal way calls exit. Even a program that returns from main() calls exit indirectly (see _start() in "lib/user/entry.c").
• The write system call for writing to fd 1, the system console. All of our test programs write to the console (the user process version of printf() is implemented this way), so they will all malfunction until write is available.
• For now, change process_wait() to an infinite loop (one that waits forever). The provided implementation returns immediately, so Pintos will power off before any processes actually get to run. You will eventually need to provide a correct implementation.

Project 3

Tasks:
1 - alarm clock
2 - priority scheduling w/o donation
3 - priority donation
4 - flag that enables advanced scheduler
5 - advanced scheduler

Dependencies:
(2) must be done before (4) and (5)
(4) MIGHT need to be done before (5); whoever is doing (4) should look into the advanced scheduler and decide

• alarm clock
• priority scheduling w/o donation
• priority donation
• flag that enables advanced scheduler
• advanced scheduler

Project 5

• Frame table without swapping. If you run out of frames, fail the allocator or panic the kernel. After this step, your kernel should still pass all the project 4 test cases.
• Supplemental page table and page fault handler. For now, consider only valid accesses. After this step, your kernel should pass all of the project 4 functionality test cases, but only some of the robustness tests.
  ===
• Frame table with swapping (aka eviction?)
• Swap table
• Table of file mappings / memory mapped files
• Stack growth
• Page reclamation on process exit

Todo

Tokenizing (Debugging): Justin Leong
Tokens to Structs: John Li
Execute Structs/External Commands: Justin Leong
Internal Commands: Christina Lin
Main Loop: Christina Lin

Buffer cache synchronization bug

On bochs, syn-read is failing on the end_read() call when run on bochs. All other regression tests pass on bochs.

cs124vm build # backtrace 0xc002984c 0xc0023c54 0xc00240e8 0xc002ff7b 0xc002ec7b 0xc002e200 0xc002d579 0xc002da29 0xc0022817 0xc0022a1f 0x804a76c 0x8048179 0x80488ea
0xc002984c: debug_panic (.../../lib/kernel/debug.c:38)
0xc0023c54: lock_release (...../../threads/synch.c:269)
0xc00240e8: end_read (...../../threads/synch.c:447)
0xc002ff7b: read_cache_offset (...../../filesys/cache.c:395)
0xc002ec7b: inode_read_at (...../../filesys/inode.c:198)
0xc002e200: file_read (...d/../../filesys/file.c:57)
0xc002d579: sys_read (...../userprog/syscall.c:388)
0xc002da29: syscall_handler (...../userprog/syscall.c:124)
0xc0022817: intr_handler (..../threads/interrupt.c:330)
0xc0022a1f: intr_entry (threads/intr-stubs.S:38)
0x0804a76c: (unknown)
0x08048179: (unknown)
0x080488ea: (unknown)
cs124vm build #