I'd like to watch the output of a UART device in Linux, and I only want to see the content when there are a whole line. So I prefer some kind of line-buffered cat such as:

There are several SAME_STACK asserts in $OS161_SRC/kern/arch/mips/locore/trap.c to ensure that current thread did not run out of kernel stack.

Sys161 will panic if you try to write a TLB entry with a entryhi, but there are already a TLB entry with the same entryhi but in a different TLB slot. This is because entryhi should be a UNIQUE key in the TLB bank.

Now that you can allocate/free physical pages, and you have demand paging through handling TLB miss. Let's get the final part work: swapping.

Now we've set up user address space, it's time to handle TLB/page faults. Note that there is a difference between TLB and page faults:

• TLB fault means the hardware don't know how to translate a virtual address since the translation didn't present in any TLB entry. So the hardware raise a TLB fault to let the kernel decide how to translate that address.

• Page fault means the user program tries to access a page that is not in memory, either not yet allocated or swapped out.

If you're not familiar with sbrk system call, here is it's wiki, and its interface description. In a nutshell, malloc will use sbrk to get heap space.

Suppose you have two machines: A and B. A is your work machine, you do most of your work on it. But B is a little special (e.g., connected to some specific hardware) that you need to ssh on it or copy some file from A to B from time to time. Here is the way that you can get rid of entering passwords every time you do ssh/scp.

Now we've set up our coremap and also have the routines to allocate and free physical pages. It's the time to set up user's virtual address space.

Basically, we'll adopt two-level page table. If you're not already familiar with this, you can check out the page table wiki and this document talking about MIPS and X86 paging.

We'll talk about page_alloc, page_free, alloc_kpages and free_kpages.

The first concern of OS161 virtual memory system is how to manage physical pages. Generally, we can pack a physical page's information into a structure (called struct coremap_entry) and use this struct to represent a physical page. We use an array of struct coremap_entry to keep all physical pages information. This array, aka, coremap, will be one of the most important data structure in this lab.