web作业 | report代写 | x86代做 | Algorithm | shell | oop | assignment作业 | lab | 代做Operating Systems – Implementing Virtual Memory in WeensyOS

2023-03-31

Implementing Virtual Memory in WeensyOS

web作业 | report代写 | x86代做 | Algorithm | shell | oop | assignment作业 | lab | 代做Operating Systems – 该题目是一个常规的os的Virtual Memory题目代写, 涉及了web/report/x86/Algorithm/shell/oop/Operating Systems等代写方面, 该题目是值得借鉴的WeensyOS代写的题目

shell代写代写 代写shell

UCL CS 0019 Brad Karp

Individual Assessed Coursework 4:

Implementing Virtual Memory in WeensyOS

Introduction

In this coursework you will implement process memory isolation, virtual memory, and a system call in a tiny (but very real!) operating system called WeensyOS. The WeensyOS kernel runs on x86-64 CPUs. Because the OS kernel runs on the bare hardware, debugging kernel code can be tough: if a bug causes misconfiguration of the hardware, the usual result is a crash of the entire kernel (and all the applications running on top of it). And because the kernel itself provides the most basic system services (e.g., causing the display hardware to display error messages, or causing the disk hardware to log them to disk) deducing what went wrong after a kernel crash can be particularly challenging. In the dark ages^1 , the usual way to develop code for an OS (whether as part of a class, in a research lab, or in industry) was to boot it on a physical CPU. The lives of kernel developers have gotten much better since. You will run WeensyOS in QEMU, which is a software-based x86-64 emulator: it looks to WeensyOS just like a physical x86- CPU, but if your WeensyOS code-in-progress wedges the (virtual) hardware, QEMU itself and the whole OS the real hardware is running (i.e., the Linux OS you booted and that QEMU is running on) survive unscathed. So, for example, your last few debuggingprintf()s before a kernel crash will still get logged to disk (by QEMU running on Linux), and rebooting the kernel youre developing amounts to re-running the QEMU emulator application. This coursework must be done on a Linux host with QEMU installed. The UCL CS lab machines that are remotely accessible by ssh already have QEMU installed. We provide simple instructions on how to install QEMU in the 0019 virtual machine (VM) provided for use in this class later in this handout (under Running WeensyOS). If you happen to have another Linux or UNIX machine at your disposal, you may be able to install QEMU on it and run WeensyOS there, but the only development environments the 0019 staff can support for CW4 are the ssh- accessible CS lab machines and the 0019 VM. Do not use Thinlinc for CW4: the Thinlinc CSRW remote desktop does not have QEMU installed, and the 0019 teaching staff unfortunately arent able to update the installed software on Thinlinc.

Chapter 9 of CS:APP/3e covers virtual memory, and offers vital background for this course-
work. Section 9.7 in particular describes the 64-bit virtual memory architecture of the x86-
64 CPU. Figure 9.23 and Section 9.7.1 show and discuss thePTEP,PTEW, andPTEUbits,
flags in the x86-64 hardwares page table entries that play a central role in this coursework.

Tasks

  • Implement complete and correct memory isolation for WeensyOS processes.
  • Implement full virtual memory, which will improve utilization.
  • Implement thefork()system call, used to create new processes at runtime.

(^1) i.e., when your instructor was an undergraduate, in a prior century

You will complete the above tasks in five stages described in detail below. Each stage has a test in this courseworks test suite, and is worth an equal share of the total marks for the coursework (i.e., 20% per stage). Weve provided you a lot of support code for this assignment, but the code you will need to write is in fact quite limited in extent. Our complete solution (for all 5 stages) consists of well under 200 lines of code beyond what we initially hand out to you. All the code you write must go inkernel.candkernel.h. This handout provides vital detail on how to interpret the graphical maps of WeensyOSs physical and virtual memory that QEMU will display to you while WeensyOS is running. Study- ing these graphical memory maps carefully is the best way to determine whether your WeensyOS code for each stage is working correctly. While we do provide tests that you can run to learn what grade your current code would receive, these tests only tell you whether each test has been passed or failed, because the graphical memory maps are already exhaustive in showing how your code behaves. In short, you will definitely want to make sure you understand how to read these maps before you start to hack. You will also find considerable guidance in how to go about implementing the functionality for each stage of the coursework in this document. Read this handout in its entirety carefully before you begin!

As ever, it is important to get started early. Kernel development is less forgiving than de-
veloping user-level applications; tiny deviations in the configuration of hardware (e.g., the
MMU) by the OS tend to bring the whole (emulated, in this case!) machine to a halt. You
will almost certainly need the two weeks allotted to complete CW4.

Getting Started

Before you follow the instructions below to retrieve the code for CW4, you MUST first
complete the 0019 grading server registration process. You only need do so once for the
entire term, and you probably did so before beginning work on CW1, CW2, and/or CW3,
in which case you need not register again.
If, however, you did none of CW1, CW2, or CW3, and have not yet registered with the
0019 grading server, STOP NOW, find the email you received with the subject line your 0019
grading server token, retrieve the instructions document at the link in that email, follow
those instructions, and only thereafter proceed with the instructions below for retrieving the
code for CW4.

We will use GitHub for CW4 in much the same manner as for CW2 and CW3. To obtain a copy of the initial code for CW4, please visit the following URL:

https://classroom.github.com/a/7ONfPHF

If youd like a refresher on using git with your own local repository and syncing it to GitHub, please refer to the CW2 handout. Each time you push updated code to your GitHub repository for CW4, our automatic grading server will pull a copy of your code, run our automated tests on your code, and place a grade report in a filereport.mdin your GitHub repository. Your mark on CW4 will be that produced by the automated tests run by our automatic grading server on the latest commit (update) you make to your GitHub repository before the CW4 deadline. More on these tests below.

Please note that your codes behavior on the automated tests when run on the 0019 grading
server will determine your mark on CW4.^2 If you choose to develop in a different environ-
ment, you must ensure that your code passes the automated tests on our automatic grading
server. (We push grade reports to your GitHub repo each time you update your code to
make it easy for you to check this.) The CS 0019 staff cannot support development envi-
ronments other than the 0019 Linux VM and the ssh-accessible 0019 machines; we cannot
diagnose problems you encounter should your code pass the tests in some other environment,
but fail them in the 0019 Linux VM.

Getting Familiar with WeensyOS Memory Maps

Once youve cloned your repository from GitHub to your working environment, you can build the initial version of WeensyOS weve given you by issuing the shell commandmake runin your CW4 directory. You should see something like the below, which shows four processes running in parallel, each running a version of the program inp-allocator:

The image above is in color, and is a single still frame from an animation. You will almost certainly want to view these memory maps in color with the animation. You can find these color animations on the 0019 class web site (along with a duplicate copy of the text in this handout that goes along with the images) at: http://www.cs.ucl.ac.uk/staff/B.Karp/0019/s2022/cw/cw4-maps/ The animated version of the above image loops forever; in an actual run, the bars will move to the right and stay there. Dont worry if your image has different numbers of Ks or otherwise has different details. If your bars run painfully slowly, edit thep-allocator.csource file and reduce theALLOCSLOWDOWN constant.

Stop now to read and understand p-allocator.c.

(^2) The only exception will be if the instructors determine that a students submission produces output that matches the expected output without implementing the required functionality; such submissions will receive zero marks.

Heres how to interpret the memory map display:
  • WeensyOS displays the current state of physical and virtual memory. Each character rep- resents 4 KB of memory: a single page. There are 2 MB of physical memory in total. (Ask yourself: how many pages is this?)
  • WeensyOS runs four processes, 1 through 4. Each process is compiled from the same source code (p-allocator.c), but linked to use a different region of memory.
  • Each process asks the kernel for more heap memory, one page at a time, until it runs out of room. As usual, each processs heap begins just above its code and global data, and ends just below its stack. The processes allocate heap memory at different rates: compared to Process 1, Process 2 allocates twice as quickly, Process 3 goes three times faster, and Process 4 goes four times faster. (A random number generator is used, so the exact rates may vary.) The marching rows of numbers (in the animated version of this map on the 0019 web site) show how quickly the heap spaces for processes 1, 2, 3, and 4 are allocated.

Here are two labeled memory maps showing what the characters mean and how memory is arranged. These are best read in color; if youre reading the black-and-white hardcopy handout, visit the 0019 web site at the link above for the color versions!

The virtual memory display is similar:
  • The virtual memory display cycles successively among the four processes address spaces. In the base version of the WeensyOS code we give you to start from, all four processes address spaces are the same (your job will be to change that!).
  • Blank spaces in the virtual memory display correspond to unmapped addresses. If a process (or the kernel) tries to access such an address, the processor will generate a page fault hardware exception.
  • The character shown at address X in the virtual memory display identifies the owner of the corresponding physical page.
  • In the virtual memory display, a character is in reverse video if an application process is allowed to access the corresponding address. Initially, any process can modify all of physical memory, including the kernel. Memory is not properly isolated.

Running WeensyOS

As noted at the start of this handout, WeensyOS runs under the QEMU x86-64 CPU emulator on Linux. If youre running on one of the ssh-accessible CS machines, they already have QEMU installed. If you are using the 0019 VirtualBox VM, though, youll need to install QEMU. Do so by issuing the shell commandsudo apt install qemu-system-x86. Youll be prompted for the VM users password, which isuser. Say yes to any prompts, and after several seconds, QEMU will be installed and ready for use in your VirtualBox VM. ReadREADME-OS.mdin your CW4 repository for information on how to run WeensyOS. If QEMUs default display causes accessibility problems, you will want to runmake run-console. To makerun-consolethe default, runexport QEMUCONSOLE=1in your shell. There are several ways to debug WeensyOS. We recommend addinglogprintf()state- ments to your code. The output oflogprintf()is written to the filelog.txt outside QEMU, into your CW4 working directory. We also recommend that you use assertions (of which we saw a few in the lecture on Undefined Behavior; tryman assertat the Linux shell to learn more) to catch problems early. For example, call the helper functions weve provided, checkpagetablemappings()andcheckpagetableownership(), to test a page ta- ble for obvious errors.

Memory System Layout

The WeensyOS memory system layout is defined by several constants: Constant Meaning KERNELSTARTADDR Start of kernel code KERNELSTACKTOP Top of kernel stack; one page long console Address of CGA console memory PROCSTARTADDR Start of application code. Applications should not be able to access memory below this address, except for the single page atconsole. MEMSIZEPHYSICAL Size of physical memory in bytes. WeensyOS does not sup- port physical addressesthis value. Defined as0x (2 MB). MEMSIZEVIRTUAL Size of virtual memory. WeensyOS does not support virtual addressesthis value. Defined as0x300000(3MB).

Writing Expressions for Addresses

WeensyOS uses several C macros to construct addresses. They are defined at the top ofx86-64.h. The most important include:

Macro Meaning
PAGESIZE Size of a memory page; defined as 4096 (or equiva-
lently, 1 << 12 )
PAGENUMBER(addr) Page number for the page containingaddr. Expands
to an expression analogous toaddr / PAGESIZE.
PAGEADDRESS(pn) The initial address (zeroth byte) in page number
pn. Expands to an expression analogous topn *
PAGESIZE.
PAGEINDEX(addr, level) The index in the levelth page table for addr.
levelmust be between 0 and 3. 0 returns the level-
page table index (address bits 3947); 1 returns the
level-2 index (bits 3038); 2 returns the level-3 index
(bits 2129); and 3 returns the level-4 index (bits 12
20).
PTEADDR(pe) The physical address contained in page table entrype.
Obtained by masking off the flag bits (setting the low-
order 12 bits to zero).

Before you begin coding, you should both understand what these macros represent and be
able to derive values for them if you were given a different page size.

Kernel and Process Address Spaces

The version of WeensyOS you receive at the start of CW4 places the kernel and all processes in a single, shared address space. This address space is defined by thekernelpagetablepage table. kernelpagetableis initialized to the identity mapping : virtual address X maps to physical address X. As you work through CW4s stages, you will shift processes to using their own independent address spaces, where each process can access only a subset of physical memory. The kernel, though, must remain able to access any location in physical memory. Therefore, all kernel functions run using thekernelpagetablepage table. Thus, in kernel functions, each virtual address maps to the physical address with the same number. Theexception() function explicitly installskernelpagetablewhen it begins. WeensyOS system calls are more expensive than they need to be, since every system call switches address spaces twice (once tokernelpagetableand once back to the processs page table). Real-world Operating Systems avoid this overhead. To do so, real-world kernels ac- cess memory using process page tables rather than a kernel-specifickernelpagetable. That makes a kernels code more complicated, though, since kernels cant always access all of physical memory directly under that design.

The Five Stages of WeensyOS

We describe below the five implementation stages you must complete in CW4: what you need to implement in each, and hints on how to do so.

Stage 1: Kernel Isolation

In the starting code weve given you, WeensyOS processes could stomp all over the kernels memory if they wanted to. Better prevent that. Changekernel(), the kernel initialization

function, so that kernel memory is inaccessible to applications, except for the memory holding the CGA console (the single page at(uintptrt) console == 0xB8000.)^3 When you are done, WeensyOS should look like the below. In the virtual map, kernel memory is no longer reverse-video, since the user cant access it. Note the lonely CGA console memory block. (As with all these maps, you will want to view the figure below in its online, color version at the URL given earlier in this handout.)

Hints:
  • Usevirtualmemorymap(). A description of this function is inkernel.h. You will benefit from reading all the function descriptions inkernel.h. You can supplyNULLfor theallocatorargument for now.
  • If you really want to look at the code forvirtualmemorymap(), it is ink-hardware.c, along with many other hardware-related functions.
  • Thepermargument tovirtualmemorymap()is a bitwise-or of zero or morePTE flags: PTEP,PTEW, andPTEU.PTEPmarks P resent pages (pages that are mapped). PTEWmarks W ritable pages. PTEUmarks U ser-accessible pagespages accessible by applications. You want kernel memory to be mapped with permissionsPTEP | PTEW, which will prevent applications from reading or writing the memory, while allowing the kernel to both read and write.
  • Make sure that yoursyspagealloc()system call preserves kernel isolation: Applica- tions shouldnt be able to usesyspagealloc()to screw up the kernel.

Stage 2: Isolated Address Spaces for Processes

Implement process isolation by giving each process its own independent page table. Your OS memory map should look like this when youre done (animated, color version online):

(^3) Making the console accessible in this way, by making the range of RAM where the contents of the display are held directly accessible to applications, is a throwback to the days of DOS, whose applications typically generated console output in precisely this way. DOS couldnt run more than one application at once, so there wasnt any risk of multiple concurrent applications clobbering one anothers display writes to the same screen locations. We borrow this primitive console design to keep WeensyOS simple and compact.

That is, each process only has permission to access its own pages. You can tell this because only its own pages are shown in reverse video. What goes in per-process page tables:

  • The initial mappings for addresses less thanPROCSTARTADDRshould be copied from those inkernelpagetable. You can use a l oop withvirtualmemorylookup() andvirtualmemorymap()to copy them. Alternately, you can copy the mappings from the kernels page table into the new page tables; this is faster, but make sure you copy the right data!
  • The initial mappings for the user areaaddresses greater than or equal toPROCSTARTADDR should be inaccessible to user processes (i.e.,PTEUshould not be set for these PTEs). In our solution (shown above), these addresses are totally inaccessible (so they show as blank), but you can also change this so that the mappings are still there, but accessible only to the kernel, as in this diagram (animated, color version online):
The reverse video shows that this OS also implements process isolation correctly.
How to implement per-process page tables:
  • Changeprocesssetup()to create per-process page tables.
  • We suggest you write acopypagetable( x86 64 pagetable *pagetable, int8t owner)function that allocates and returns a new page table, initialized as a full copy of pagetable(including all mappings frompagetable). This function will be useful in Stage 5. Inprocesssetup()you can modify the page table returned bycopypagetable() according to the requirements above. Your function can usepageinfo[]to find free pages to use for page tables. Read aboutpageinfo[]at the top ofkernel.c.
  • Remember that the x86-64 architecture uses four-level page tables.
  • The easiest way to copy page tables involves an allocator function suitable for passing to virtualmemorymap().
  • Youll need at least to allocate a level-1 page table and initialize it to zero. You can also set up the whole four-level page table skeleton (for addresses0…MEMSIZEVIRTUAL – 1) yourself; then you dont need an allocator function.
  • A physical page is free ifpageinfo[PAGENUMBER].refcount == 0. Look at the other code inkernel.cfor some hints on how to examine thepageinfo[]array.
  • All of processPs page table pages must havepageinfo[…].owner == Por Ween- syOSs consistency-checking functions will fail. This will affect your allocator function. (Hint: Dont forget that global variables are allowed in your code!)

If you create an incorrect page table, WeensyOS might crazily reboot. Dont panic! Add logprintf()statements. Another useful technique that may at first seem counterintuitive: add infinite loops to your kernel to track down exactly where a fault occurs. (If the OS hangs without crashing once youve added an infinite loop, then the crash youre debugging must occur at a point in the kernels execution after your infinite loops place in the code.)

Stage 3: Virtual Page Allocation

Thus far in CW4, WeensyOS processes have used physical page allocation : the page with phys- ical address X is used to satisfy thesyspagealloc(X)allocation request for virtual ad- dress X. This strategy is inflexible and limits utilization. Change the implementation of the INTSYSPAGEALLOCsystem call so that it can use any free physical page to satisfy asyspagealloc(X) request. Your newINTSYSPAGEALLOCcode must perform the following tasks:

  • Find a free physical page using thepageinfo[]array. Return-1to the application if you cant find one. Use any Algorithm youd like to find a free physical page; in our model solution, we just return the first one we find.
  • Record the physical pages allocation inpageinfo[].
  • Map that physical page at the requested virtual address.

Dont modify thephysicalpagealloc()helper function, which is also used by the pro- gram loader. You can write a new function if you need to. Heres how our OS looks after this stage (animated, color version online):

Stage 4: Overlapping Virtual Address Spaces

Now the processes are isolated, which is excellent. But theyre still not taking full advantage of virtual memory. Isolated address spaces can use the same virtual addresses for different physical memory. Theres no need to keep the four processes address spaces disjoint. In this stage, change each processs stack to start from address0x300000 == MEMSIZEVIRTUAL. Now the processes have enough heap room to use up all of physical memory! Heres how the memory map will look after youve done it successfully (animated, color version online):

If theres no physical memory available,syspagealloc()should return an error to the caller (by returning -1). Our model solution additionally prints Out of physical memory! to the console when this happens; you dont need to.

Stage 5: Fork

Thefork()system call is one of Unixs great ideas. It starts a new process as a copy of an existing one. Thefork()system call appears to return twice, once to each process. To the child process, it returns 0. To the parent process, it returns the childs process ID. Run WeensyOS withmake runormake run-console. At any time, press the f key. This will soft-reboot WeensyOS and cause it to run a single process from thep-forkapplication, rather than the gang ofallocatorprocesses. You should see something like this in the memory map (color version online):

Thats because you havent implementedfork()yet.

How to implementfork():
  • When a process callsfork(), look for a free process slot in theprocesses[]array. Dont use slot 0. If no free slot exists, return-1to the caller.
  • If a free slot is found, make a copy ofcurrent->ppagetable, the forking processs page table, using your function from earlier.
  • But you must also copy the process data in every application page shared by the two pro- cesses. The processes should not share any writable memory except the console (otherwise they wouldnt be isolated). Sofork()must examine every virtual address in the old page table. Whenever the parent process has an application-writable page at virtual addressV, thenfork()must allocate a new physical pageP; copy the data from the parents page intoPusingmemcpy(); and finally map pagePat addressVin the child processs page table. (Theres a Linux man page formemcpy().)
  • The child processs registers are initialized as a copy of the parent processs registers, except forregrax.
  • Usevirtualmemorylookup()to query the mapping between virtual and physical ad- dresses in a page table.

When youre done, you should see something like the below after pressing f (animated, color version online):

An image like the below, however, means you forgot to copy the data for some pages, so the processes are actually sharing stack and/or data pages when they should not (animated, color version online):

Tips

The kernel defines a constant,HZ, which determines how many times per second the kernels clock ticks. Dont change this valuethere is absolutely no need to do so while solving CW4, and doing so will likely cause your code to fail our tests! After you run any of our per-stagemake grade-Ntests (see below), if you happen to exam- ine thelog.txtfile, youll see a vast amount of output therein that we generate for use in the automated tests. You can ignore it (and it will be absent when you run withmake runwhile you are developing, so it wont clutter your own debugginglogprintf()s in those runs).

Running the Tests and Submitting

Unlike for prior courseworks in 0019, the automated tests for CW4 are not intended to
help you debug! As stated at the start of this handout, the visual memory map displayed
by QEMU as your WeensyOS kernel runs is the best way to determine how your code is
behaving in all the stages of CW4. The automated tests for CW4 are simply for you to
confirm that youve completed a stage (and they are the tests the grading server will use to
assign grades). So run withmake runto visualize how memory is being used while you are
coding and validating your design. Then only switch to the automated tests below when you
think youre done a stage and want to double-check.

There are five tests, one for each stage. You can run each of them with the shell commandsmake grade-onethroughgrade-five. Note that the stage numbers are written out in text and not using digits. Each stages result is all-or-nothing; pass or fail. The tests report success or failure, and nothing more (see abovethe graphical memory map is how you should determine how your code is behaving). There are three invariants in all five stages tests that your code must uphold; if your code doesnt uphold any invariant, youll receive an error to that effect and fail the test (regardless of stage). These invariants are:

  • The CGA console must be accessible by all processes (this requirement is discussed in the text above on stage 1).
  • If we consider processP, there should be no virtual page inPs page table at a user-space address (i.e., whose address is above the kernel/user virtual address split point) that is owned byPbut not accessible byP.
  • When we run our tests, we configure the WeensyOS kernel to exit after 10 seconds of execu- tion (1000 WeensyOS kernel ticks).^4 If a bug in your code makes the kernel crash before 1000 WeensyOS kernel ticks, youll fail the test on which that happens. Alternatively, if your kernel enters an infinite loop, and thus never reaches our exit at 1000 ticks: – When you run the tests locally in your VM, the VM will get stuck in the infinite loop and never exit, so the tests will hang and youll need to terminate your hung kernel. Do so by opening another terminal window and issuing the commandmake kill, which will kill all QEMU processes you have running. – When the grading server runs the tests, it will eventually time out and kill the entire VM where the tests of your code are running after 10 minutes (which will cause you to fail all tests).

These invariants are reasonable: regardless of what your memory map display looks like, a good solution should neither crash nor enter an infinite loop. There is only onekernel.cfile; you implement the five stages cumulatively in it. As such, when you add further stages functionality, you should not break that of prior stages. You can confirm this visually when you scrutinize the memory map shown by QEMU. Our tests also verify it: each stages test runs all prior stages tests. If any of the prior stages tests fail, the current stages test is deemed to have failed. One interesting consequence of the cumulative nature of CW4 is that if you introduce a regression in your changes for some stage after the first stage that causes one or more prior stages tests to fail, youll not only lose the marks for the current stage you are working on, but also lose them for any prior stage whose tests your regression causes to fail. If you need to submit (whether at the deadline or late), and find this has happened, do not despair: simply revert your code to the last good version before your regression (using the life-saving history provided by GitHubso do make sure you commit and push often!), and youll be back to passing those earlier stages tests again. Once again, we urge you to get started early.

Submitting via GitHub

We will deem the timestamp of your CW4 submission to be the timestamp on GitHubs server of the last push you make before the submission deadline of 4 PM GMT on 10th March 2022. Your mark will be the mark you receive on the automated tests for that version of your code. 0019 follows the UCL-wide standard late coursework penalties, as described on the 0019 class web site. If you wish to submit after the deadline, you must take the following steps for your course- work to be marked:

  1. When you wish to receive a mark for a version of your code that you push to GitHub after the submission deadline, you must begin your commit log message for that commit with

(^4) We also disableALLOCSLOWDOWNinp-allocator.candp-fork.cduring our tests, so that memory allo- cation proceeds much more quickly, at machine speed rather than human-vision speed. Thus 1000 ticks are plenty of time for the workload to run and exhibit how your kernels virtual memory system behaves.

the exact stringLATESUBMIT. Our grading system will not record a mark for your late
submission unless you comply with this requirement. We follow this policy so that if a
student accidentally pushes a further commit after the deadline, they arent penalized for a
late submission.
  1. You may make only one late submission (i.e., one GitHub commit with the initial string LATESUBMIT. If you make more than one late submission, we will only mark the first one.

Academic Honesty

This coursework is an individual coursework. Every line of code you submit must have been written by you alone, and must not be a reproduction of the work of otherswhether from the work of students in this (or any other) class from this year or prior years, from the Internet, or elsewhere (where elsewhere includes code written by anyone anywhere). Students are permitted to discuss with one another the definition of a problem posed in the coursework and the general outline of an approach to a solution, but not the details of or code for a solution. Students are strictly prohibited from showing their solutions to any problem (in code or prose) to a student from this year or in future years. In accordance with academic practice, students must cite all sources used; thus, if you discuss a problem with another student, you must state in your solution that you did so, and what the discussion entailed. Anyuse of any online question-and-answer forum (other than the CS 0019 Piazza web site) to obtain assistance on this coursework is strictly prohibited, constitutes academic dishonesty, and will be dealt with in the same way as copying of code. Reading any online material specifically directed toward solving this coursework is also strictly prohibited, and will also be dealt with in the same way. You are free to read other reference materials found on the Internet (and any other reference materials), apart from any source code that implements x86 virtual memory. You may of course use the code we have given you. Again, all other code you submit must be written by you alone. Copying of code from student to student (or by a student from the Internet or elsewhere) is a serious infraction; it typically results in awarding of zero marks to all students involved, and is viewed by the UCL administration as cheating under the regulations concerning Plagia- rism, Collusion, and/or Falsification. Penalties imposed can include exclusion from all further examinations at UCL. The course staff use extremely accurate plagiarism detection software to compare code submitted by all students (as well as code found on the Internet) and identify in- stances of copying of code; this software sees through attempted obfuscations such as renaming of variables and reformatting, and compares the actual parse trees of the code. Rest assured that it is far more work to modify someone elses code to evade the plagiarism detector than to write code for the assignment yourself!

Read the Piazza Web Site

You will find it useful to monitor the 0019 Piazza web site during the period between now and the due date for the coursework. Any announcements ( e.g., helpful tips on how to work around unexpected problems encountered by others) will be posted there. And you may ask questions there. Please remember that if you wish to ask a question that reveals the design of your solution, you must mark your post on Piazza as private, so that only the instructors may see it. Questions about the interpretation of the coursework text, or general questions about C that do not relate to your solution, however, may be asked publiclyand we encourage you to do so, so that the whole class benefits from the discussion.

References

CS:APP/3e Chapter 9, particularly9.

Acknowledgement

Eddie Kohler created WeensyOS.