This is an undergraduate operating systems class that requires x86 assembly language and C language basics such as data structures, stacks, queues, and pointers. I will attach pdf of the lab with instructions and the .c files which code must be written in. In the lab I need exercises 1, 4, 5 to be coded and with comments. In the .c file and in the exercise in the lab manual clearly mentions in which functions the code must be completed. Fill in the code in those sections. Important instructions: DONOT COPY CODE FROM INTERNET SOURCES LIKE CHEGG, COURSEHERO OR GITHUB. I WANT PLAGERSIM FREE CODE, I HAVE ACCESS TO ALL THOSE ALREADY. ALSO I WANT A GOOD EXPERT WITH KNOWLEDGE IN operating systems that requires x86 assembly language and C language basics such as data structures, stacks, queues, and pointers.
Docs » Lab Assignments » Lab 2: Memory Management Lab 2: Memory Management Handed out: 09/09/2022 (Fri) Due: 10/02/2022 (Sun) 11:59pm Introduction In this lab, you will write the memory management code for your operating system. Memory management has two components. The �rst component is a physical memory allocator for the kernel, so that the kernel can allocate memory and later free it. Your allocator will operate in units of 4096 bytes, called pages. Your task will be to maintain data structures that record which physical pages are free and which are allocated, and how many processes are sharing each allocated page. You will also write the routines to allocate and free pages of memory. The second component of memory management is virtual memory, which maps the virtual addresses used by the kernel and user software to address in physical memory. The x86 hardware's memory management unit (MMU) performs the mapping when instructions use memory, consulting a set of page tables. You will modify JOS to set up the MMU's page tables according to a speci�cation we provide. Getting started In this and future labs you will progressively build up your kernel. We will also provide you with some additional source. To fetch that source, use Git to commit changes you've made since handing in Lab 1 (if any), fetch the latest version of the course repository, and then create a local branch called lab2 based on our lab2 branch, origin/lab2 in the lab repository: https://crs.s3lab.io/cs4348/2022/fall/index.html https://crs.s3lab.io/cs4348/2022/fall/lab.html http://s3lab.utdallas.edu/cs4348/jos $ cd ~/jos $ git add -A $ git commit -am 'changes to lab1 after handin' Created commit 734fab7: changes to lab1 after handin 3 files changed, 28 insertions(+), 7 deletions(-) $ git pull Already up-to-date. $ git remote add cs4348 ssh://
[email protected]:2224/cs4348/jos.git $ git fetch cs4348 remote: Enumerating objects: 20, done. remote: Counting objects: 100% (20/20), done. remote: Compressing objects: 100% (12/12), done. remote: Total 13 (delta 5), reused 0 (delta 0), pack-reused 0 Unpacking objects: 100% (13/13), 10.83 KiB | 2.71 MiB/s, done. From ssh://s3lab.utdallas.edu:2224/cs4348/jos * [new branch] lab1 -> cs4348/lab1 * [new branch] lab2 -> cs4348/lab2 $ git checkout -b lab2 cs4348/lab2 Branch 'lab2' set up to track remote branch 'lab2' from 'cs4348'. Switched to a new branch 'lab2' $ git push -u origin lab2:lab2 Enumerating objects: 20, done. Counting objects: 100% (20/20), done. Delta compression using up to 4 threads Compressing objects: 100% (12/12), done. Writing objects: 100% (13/13), 10.84 KiB | 3.61 MiB/s, done. Total 13 (delta 5), reused 0 (delta 0), pack-reused 0 remote: remote: To create a merge request for lab2, visit: remote: http://s3lab.utdallas.edu/cxk200010/jos/-/merge_requests/new? merge_request%5Bsource_branch%5D=lab2 remote: To ssh://s3lab.utdallas.edu:2224/cxk200010/jos.git * [new branch] lab2 -> lab2 Branch 'lab2' set up to track remote branch 'lab2' from 'origin'. $ git remote rm cs4348 $ The git checkout -b command shown above actually does two things: it �rst creates a local branch lab2 that is based on the cs4348/lab2 branch provided by the course staff, and second, it changes the contents of your lab directory to re�ect the �les stored on the lab2 branch. The git push -u command creates your own remote branch origin/lab2 and connects it to the local branch lab2 , so your Lab 2 submission can be uploaded to your own remote branch when you run git push later. Git allows switching between existing branches using git checkout branch-name (change branch-name to the branch name you want to switch to), though you should commit any outstanding changes on one branch before switching to a different one. The git remote rm command removes the course staff repository that you added earlier using the git remote add command. You will now need to merge the changes you made in your lab1 branch into the lab2 branch, as follows: $ git merge lab1 Merge made by recursive. kern/kdebug.c | 11 +++++++++-- kern/monitor.c | 19 +++++++++++++++++++ lib/printfmt.c | 7 +++---- 3 files changed, 31 insertions(+), 6 deletions(-) $ In some cases, Git may not be able to �gure out how to merge your changes with the new lab assignment (e.g. if you modi�ed some of the code that is changed in the second lab assignment). In that case, the git merge command will tell you which �les are con�icted, and you should �rst resolve the con�ict (by editing the relevant �les) and then commit the resulting �les with git commit -a . Lab 2 contains the following new source �les, which you should browse through: inc/memlayout.h kern/pmap.c kern/pmap.h kern/kclock.h kern/kclock.c memlayout.h describes the layout of the virtual address space that you must implement by modifying pmap.c . memlayout.h and pmap.h de�ne the PageInfo structure that you'll use to keep track of which pages of physical memory are free. kclock.c and kclock.h manipulate the PC's battery-backed clock and CMOS RAM hardware, in which the BIOS records the amount of physical memory the PC contains, among other things. The code in pmap.c needs to read this device hardware in order to �gure out how much physical memory there is, but that part of the code is done for you: you do not need to know the details of how the CMOS hardware works. Pay particular attention to memlayout.h and pmap.h , since this lab requires you to use and understand many of the de�nitions they contain. You may want to review inc/mmu.h , too, as it also contains a number of de�nitions that will be useful for this lab. Lab requirements In this lab and subsequent labs, do all of the regular exercises described in the lab and provide a writeup that brie�y answers to the questions posed in the lab. Please place the write-up in a �le called answers-lab2.txt in the top level of your directory before handing in your work. Passing all of the automated tests by make grade will give you a total of 70 points. There are six questions to answer in the write-up and each question is worth 5 points (6 x 5 points = 30 points). Hand-in procedure When you are ready to hand in your lab code and write-up, add your answers-lab2.txt to the Git repository, commit your changes, and then tag your commit with lab2-final as the �nal to submit the lab. $ git add answers-lab2.txt $ git commit -am "my answer to lab2" [lab2 a823de9] my answer to lab2 4 files changed, 87 insertions(+), 10 deletions(-) $ make grade # check your result! $ git tag lab2-final $ git push $ git push origin --tags As before, we will be grading your solutions with a grading program. You can run make grade in the lab directory to test your kernel with the grading program. You may change any of the kernel source and header �les you need to in order to complete the lab, but needless to say you must not change or otherwise subvert the grading code. Part 1: Physical Page Management The operating system must keep track of which parts of physical RAM are free and which are currently in use. JOS manages the PC's physical memory with page granularity so that it can use the MMU to map and protect each piece of allocated memory. You'll now write the physical page allocator. It keeps track of which pages are free with a linked list of struct PageInfo objects (which, unlike xv6, are not embedded in the free pages themselves), each corresponding to a physical page. You need to write the physical page allocator before you can write the rest of the virtual memory implementation, because your page table management code will need to allocate physical memory in which to store page tables. Note Exercise 1. In the �le kern/pmap.c , you must implement code for the following functions (probably in the order given). boot_alloc() mem_init() (only up to the call to check_page_free_list(1)) page_init() page_alloc() page_free() check_page_free_list() and check_page_alloc() test your physical page allocator. You should boot JOS and see whether check_page_alloc() reports success. Fix your code so that it passes. You may �nd it helpful to add your own assert() to verify that your assumptions are correct. This lab, and all the subsequent labs, will require you to do a bit of detective work to �gure out exactly what you need to do. This instruction does not describe all the details of the code you'll have to add to JOS. Look for comments in the parts of the JOS source that you have to modify; those comments often contain speci�cations and hints. You will also need to look at related parts of JOS, in the Intel manuals. Part 2: Virtual Memory Before doing anything else, familiarize yourself with the x86's protected-mode memory management architecture: namely segmentation and page translation. Note Exercise 2. Look at chapters 5 and 6 of the Intel 80386 Reference Manual, if you haven't done so already. Read the sections about page translation and page-based protection closely (5.2 and 6.4). We recommend that you also skim the sections about segmentation; while JOS uses paging for virtual memory and protection, segment translation and segment-based protection cannot be disabled on the x86, so you will need a basic understanding of it. Virtual, linear, and physical addresses In x86 terminology, a virtual address consists of a segment selector and an offset within the segment. A linear address is what you get after segment translation but before page translation. A physical address is what you �nally get after both segment and page translation and what ultimately goes out on the hardware bus to your RAM. http://www.logix.cz/michal/doc/i386/ Selector +--------------+ +-----------+ ---------->| | | | | Segmentation |