A little summary of previous MIT 6.828 exercises

Previously did MIT 6.828 Lab1-lab6 practice, is very old 2004 version, should be a little brother's request to paste out, and do a small summary, but also for the brother now do a little reference.

URL is http://pdos.csail.mit.edu/6.828/2004/schedule.html

My solution is http://download.csdn.net/source/397897, LAB6, Lab1-lab5 are included. is not a standard answer, and it is possible that a certain part of the bug, so that finally I may be a bit out of the question, if there is a problem in any place please let me or discuss with me, my email is dennis.he.2005@gmail.com. I should have measured most of the tests he offered. In addition, as long as it is challenge I did not do, I started the strategy is to finish 6 lab basic exercise and then do challenge, but really do later also made lazy, hehe, sorry. Brothers, if challenge did, you can discuss this.

The development environment at that time was Red Hat Enterprise.

LAB1:
Need to understand some basic knowledge of the PC, such as boot strap, real mode and protected mode x86 addressing method, etc., is also familiar with the Bochs debugging environment. The actual need to do is only a backtrace function, nothing to say, look at x86 calling convention, hands on the Bochs up test on OK.
LAB2:
The first step is to understand x86 's paging management and the conversion process of virtual address-->linear address-->physical address, and also to understand the table Inc/pmap.h in Jos code. Exercise 3 is the page table mapping to implement boot, which is done according to that mapping table and its hints; Exercise 4 is annoying, the trouble is that it is associated with the back of a large, first through its many assert will need to take some effort, In addition, the following lab errors are often found in the wrong place. When I do it personally, I think it's important to note that 1.page_insert does not need to remove the current existing one when dealing with mapping the same virtual address to the same physical page, but needs to modify the permission;2. The page_remove only needs to reduce the refcount of the page where the PTEs are located, such as the case where the same physical page is mapped to a different virtual address, only if the page that needs remove RefCount is 0; 3. Whether it is Page_insert and Page_remove, as long as the page table has been modified, must be tlb_invalidate, otherwise immediately after the memory access is likely to error, this in the Lab4 debugging can be seen.
LAB3:
LAB3 is the environment in which the user state is run. Exercise 1 is very simple, just a map of a Uenvs area. Exercise 2 of the Load_icode a bit, the first User Program page directory can be copied directly boot_pgdir, because the kernel State uses the page table entry, that is, 0xf0000000 above that part of the mapping is shared by all user environment and will not be modified, Then the load user program needs to use the page table first built, and then through the LCR3 page table from Boot_pgdir to the User Environment page table, it is simple to use memcpy directly copy the user program code and data segment. Exercise 4 is the kernel response part of the trap, and requires a careful understanding of the x86 interrupt exception handling mechanism. It is important to note that the Jos Task Register is not modified, that is, all tasks share the same kernel-state exception handling stack. The documentation and code comments are very clear about the other processes. Debug with Bochs internal Debugger,vbreak 0x1b:<int 0x30 code address, and then track the situation when the exception.
LAB4:
Exercise 1 Implementation of a simple Round-robin scheduler, hehe, there should be no more earth than this scheduler. Exercise 2 is to implement a set of system calls, mainly for the future Fork/spawn and file System preparation, if LAB2 in the Page_insert and Page_remove do bad, then Sys_mem_map and sys_mem_ Unmap will encounter a lot of problems, if you find a problem in the test, you may have to go back to lab2 redo again. The next part B is what I think is the most troublesome of the six labs. First of all to understand that he is to use the user-state program to deal with the fault pages, and the usual inertia thinking, the whole process is the user state access anomaly---------page_fault_handler processing function of the user state-- The user state where the access exception occurred. This later I thought about actually the process of processing the signal in Linux. wherein, the kernel state program needs to set the user state Page_fault_handler function uses the stack, Jos to is uxstack, in his description, the first 5 word empty, I think is used to save the general register, and then the Eip,eflags,esp,error Code and Fault_va, obviously, Fault_va and error code are used to pass to Page_fault_handler, so the user-state program exception handling of the entry of the Assembly before calling the C program to set the stack exactly at the Fault_va place. In the user state program Page_fault_handler processing needs to think clearly several questions: 1. Page_fault_handler requires a system call to sink into the kernel state, and still use the kernel common stack kstacktop;2 after sinking into the kernel state. Page_fault_handler allowed to repeat the exception, that is, nested, when the kernel is passed to the user state stack need to reserve more than two word user state returned to the user state of the EIP and EFlags, which will naturally encounter when debugging; 3. How to restore EFlags. With POPFD/POPFL, how the user state returns to the user state. Of course, is RET, recalled x86 calling convention can be. In addition, he left 5 word to the general register, I checked the data x86 Caller-save register only EAX,ECX and edx, the other 5 are all callee-saved, I do not know which two suitable, anyway EBP and ESP is absolutely not needed, I left 6 word, and I was pressed aside for EBP and esp. Exercise 8 is the implementation of Copy-on-write, and is the user-state implementation of Copy-on-write. First of all to fully understand the role of VPD and VPT, this is a user-state access to the Kernel State page table entries in a very sophisticated way, for a user-State address VA, Vpd[va>>pdshift] read the page table, and vpt[va>> Pgshift] Read the page table entry Pte,vpt[va>>pgshift] only when Vpd[va>>pdshift] exists, it makes sense, I think for a long time to understand, Khan. Secondly, in implementing Duppage, the parent process will not only set the page of the child process to cow, but also set its own to cow. Part C is the implementation of IPC, according to his tips to walk on it. Interesting is that the USER/PRIME.C test program, is used to find all the prime number, the principle of the plan9 he gave to the link page, this algorithm is feasible to find prime numbers, but the cost is terrible, hehe.
LAB5:
LAB5 is the implementation of a file system, file system Meta-data is very simple, but the problem is that the file system implementation is very unique, he put the entire file system is implemented in the user state, by a fileserver to handle all the file access requests, and use LAB4 IPC to implement a Client-server file system mode. His page_cache is a simple mapping because the Block_size and page size are consistent, and only 4 m is designed to simplify the maximum length of the file. In addition he was very extravagant in using a page to store struct fd such a few bytes of structure, in fact, in order to satisfy his IPC communication is a page requirement. Exercise 7 is the implementation of spawn, and we are familiar with the exec is not the same place is spawn by the parent process for the child process load code, and exec is the child process itself, because Jos FileSystem is implemented in the user state, The child process cannot kill itself in the user State itself. I realized that the lib/spawn.c did not strictly follow his instructions to do, I do not matter whether the text paragraph, data section or BSS section are used with the TMP page to copy, diagram, I was.
LAB6:
Lab6 is basically a synthesis, the previous implementation of the existing bug can be reflected here, it is likely to return to a lab to re-implement the code again. Other follow-up instructions to do it, the error of the crazy printing, always find out why.