and some META NAME stuff + # can be used for <style> <script>, <meta> tags + $T2H_EXTRA_HEAD = "<LINK REL=\"stylesheet\" HREF=\"pintos.css\">"; +} +1; diff --git a/doc/pintos.css b/doc/pintos.css new file mode 100644 index 0000000..b00c2ce --- /dev/null +++ b/doc/pintos.css @@ -0,0 +1,128 @@ +body { + background: white; + color: black; + padding: 0em 12em 0em 3em; + margin: 0 +} +body>p { + margin: 0pt 0pt 0pt 0em +} +body>p + p { + margin: .75em 0pt 0pt 0pt +} +H1 { + font-size: 150%; + margin-left: -1.33em +} +H2 { + font-size: 125%; + font-weight: bold; + margin-left: -.8em +} +H3 { + font-size: 100%; + font-weight: bold; + margin-left: -.5em } +H4 { + font-size: 100%; + margin-left: 0em +} +H1, H2, H3, H4, H5, H6 { + font-family: sans-serif; + color: blue +} +html { + margin: 0 +} +code { + font-family: sans-serif +} + +a:link { + color: blue; + text-decoration: none; +} +a:visited { + color: gray; + text-decoration: none; +} +a:active { + color: black; + text-decoration: none; +} +a:hover { + text-decoration: underline +} + +div.menu { + margin: 0; + font-size: 80%; + font-weight: bold; + line-height: 1.1; + text-align: center; + position: absolute; + top: 2em; + left: auto; + width: 8.5em; + right: 2em; +} +div.menu p, span.menuitem { + display: block; + margin: 0; + padding: 0.3em 0.4em; + font-family: Arial, sans-serif; + background: #ddd; + border: thin outset #000; + color: #000; + text-indent: 0em; +} +IMG.menuimg { + width: 50%; + height: auto; + border-width: 0 +} + +div.menu a, div.menu em { + display: block; + margin: 0 0.5em +} +div.menu a, div.menu em { + border-top: 2px groove #000 +} +div.menu a:first-child { + border-top: none +} +div.menu em { + color: #fff +} + +div.menu a:link { + text-decoration: none; + color: blue +} +div.menu a:visited { + text-decoration: none; + color: gray +} +div.menu a:hover { + background: blue; + color: white +} + +div.menu span.menugap + span.menuitem { + display: block; + margin-top: 1em +} + +span.hide { + display: none +} + +body>div.menu { + position: fixed +} + +address { + font-size: 90%; + font-style: normal +} diff --git a/doc/threads.texi b/doc/threads.texi index 3cb049a..451eff8 100644 --- a/doc/threads.texi +++ b/doc/threads.texi @@ -471,6 +471,18 @@ problems. There are other, equally correct solutions that do not require interrupt manipulation. However, if you do manipulate interrupts and @strong{correctly and fully document it} in your design document, we will allow limited use of interrupt disabling. + +@item +@b{What does ``warning: no previous prototype for `@var{function}'' +mean?} + +It means that you defined a non-@code{static} function without +preceding it by a prototype. Because non-@code{static} functions are +intended for use by other @file{.c} files, for safety they should be +prototyped in a header file included before their definition. To fix +the problem, add a prototype in a header file that you include, or, if +the function isn't actually used by other @file{.c} files, make it +@code{static}. @end enumerate @item Alarm Clock FAQs diff --git a/doc/userprog.texi b/doc/userprog.texi index a729418..1e18511 100644 --- a/doc/userprog.texi +++ b/doc/userprog.texi @@ -529,9 +529,9 @@ Each character is 1 byte. @end itemize @item -@b{Why doesn't keyboard input work with @option{-nv}?} +@b{Why doesn't keyboard input work with @option{-v}?} -Serial input isn't implemented. Don't use @option{-nv} if you want to +Serial input isn't implemented. Don't use @option{-v} if you want to use the shell or otherwise type at the keyboard. @end enumerate diff --git a/doc/vm.texi b/doc/vm.texi index fa511cd..299eea1 100644 --- a/doc/vm.texi +++ b/doc/vm.texi @@ -46,13 +46,13 @@ Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in It is important for you to note that in addition to getting virtual memory working, this assignment is also meant to be an open-ended design problem. We will expect you to come up with a design that -makes sense. You will have the freedom to choose how to do software -translation on TLB misses, how to represent the swap partition, how to -implement paging, etc. In each case, we will expect you to provide a -defensible justification in your design documentation as to why your -choices are reasonable. You should evaluate your design on all the -available criteria: speed of handling a page fault, space overhead in -memory, minimizing the number of page faults, simplicity, etc. +makes sense. You will have the freedom to choose how to handle page +faults, how to organize the swap disk, how to implement paging, etc. +In each case, we will expect you to provide a defensible justification +in your design documentation as to why your choices are reasonable. +You should evaluate your design on all the available criteria: speed +of handling a page fault, space overhead in memory, minimizing the +number of page faults, simplicity, etc. In keeping with this, you will find that we are going to say as little as possible about how to do things. Instead we will focus on what end @@ -304,29 +304,22 @@ any implementation you like, as long as it accomplishes the goal. @node Problem 3-2 Paging To and From Disk @section Problem 3-2: Paging To and From Disk -Implement paging to and from disk. +Implement paging to and from files and the swap disk. You may use the +disk on interface @code{hd1:1} as the swap disk. You will need routines to move a page from memory to disk and from -disk to memory. You may use the Pintos file system for swap space, or -you may use the disk on interface @code{hd1:1}, which is otherwise -unused. A swap disk can theoretically be faster than using the file -system, because it avoid file system overhead and because the swap -disk and file system disk will be on separate hard disk controllers. -You will definitely need to be able to retrieve pages from files in -any case, so to avoid special cases it may be easier to use a file for -swap. You will still be using the basic file system provided with -Pintos. If you do everything correctly, your VM should still work -when you implement your own file system for the next assignment. +disk to memory, where ``disk'' is either a file or the swap disk. If +you do everything correctly, your VM should still work when you +implement your own file system for the next assignment. You will need a way to track pages which are used by a process but which are not in physical memory, to fully handle page faults. Pages -that you store on disk should not be constrained to be in sequential -order, and consequently your swap file (or swap disk) should not -require unused empty space. You will also need a way to track all of -the physical memory pages, in order to find an unused one when needed, -or to evict a page when memory is needed but no empty pages are -available. The data structures that you designed in part 1 should do -most of the work for you. +that you write to swap should not be constrained to be in sequential +order. You will also need a way to track all of the physical memory +pages, in order to find an unused one when needed, or to evict a page +when memory is needed but no empty pages are available. The data +structures that you designed in part 1 should do most of the work for +you. You will need a page replacement algorithm. The hardware sets the accessed and dirty bits when it accesses memory. Therefore, you @@ -503,17 +496,10 @@ the linker manual, accessible via @samp{info ld}. @item Page Table Management FAQs @enumerate 1 @item -@b{How do we manage allocation of pages used for page tables?} +@b{Do page tables need to created lazily?} -You can use any reasonable algorithm to do so. However, you should -make sure that memory used for page tables doesn't grow so much that -it encroaches deeply on the memory used for data pages. - -Here is one reasonable algorithm. At OS boot time, reserve some fixed -number of pages for page tables. Then, each time a new page table -page is needed, select one of these pages in ``round robin'' fashion. -If the page in use, clean up any pointers to it. Then use it for the -new page table page. +No. You can create the page tables at load time (or @code{mmap} time) +if you like. @item @b{Our code handles the PageFault exceptions. However, the number of @@ -530,11 +516,23 @@ you handle a page fault in your code. @enumerate 1 @item -@b{Can we assume (and enforce) that the user's stack will -never increase beyond one page?} +@item +@b{Does the virtual memory system need to support growth of the stack +segment?} + +Yes. If a page fault appears just below the last stack segment page, +you must add a new page to the bottom of the stack. It is impossible +to predict how large the stack will grow at compile time, so we must +allocate pages as necessary. You should only allocate additional pages +if they ``appear'' to be stack accesses. + +@item +@b{Does the first stack page need to be loaded lazily?} -No. This value was useful for project 2, but for this assignment, you -need to implement an extensible stack segment. +No, you can initialize the first stack page with the command line at +load time. There's no need to wait for it to be faulted in. Even if +you did wait, the very first instruction in the user program is likely +to be one that faults in the page. @item @b{Does the virtual memory system need to support growth of the data @@ -547,16 +545,6 @@ Implementing @code{sbrk()} has been an extra-credit assignment in previous years, but adds little additional complexity to a well-designed system. -@item -@b{Does the virtual memory system need to support growth of the stack -segment?} - -Yes. If a page fault appears just below the last stack segment page, -you must add a new page to the bottom of the stack. It is impossible -to predict how large the stack will grow at compile time, so we must -allocate pages as necessary. You should only allocate additional pages -if they ``appear'' to be stack accesses. - @item @b{But what do you mean by ``appear'' to be stack accesses? How big can a stack growth be? Under what circumstances do we grow the stack?} @@ -679,3 +667,5 @@ No, once created the mapping is valid until @code{munmap} is called or the process exits. @end enumerate @end enumerate + +TLB invalidation FIXME -- 2.30.2

From b11369bca8a2f9f855ff0e779bfee174e7d69ea9 Mon Sep 17 00:00:00 2001 From: Ben Pfaff Date: Sun, 26 Sep 2004 02:49:43 +0000 Subject: [PATCH] Update docs. --- doc/Makefile | 2 +- doc/intro.texi | 6 +-- doc/pintos-t2h.init | 16 ++++++ doc/pintos.css | 128 ++++++++++++++++++++++++++++++++++++++++++++ doc/threads.texi | 12 +++++ doc/userprog.texi | 4 +- doc/vm.texi | 88 ++++++++++++++---------------- 7 files changed, 201 insertions(+), 55 deletions(-) create mode 100644 doc/pintos-t2h.init create mode 100644 doc/pintos.css diff --git a/doc/Makefile b/doc/Makefile index 88c9e85..69ea110 100644 --- a/doc/Makefile +++ b/doc/Makefile @@ -4,7 +4,7 @@ filesys.texi vm.texi standards.texi doc.texi devel.texi debug.texi all: projects.html projects.info projects.html: $(TEXIS) mlfqs1.png mlfqs2.png - texi2html -toc_file=$@ -split=chapter -no-sec_nav -no-menu $< + texi2html -toc_file=$@ -split=chapter -no-sec_nav -no-menu -init_file pintos-t2h.init $< projects.info: $(TEXIS) makeinfo $< diff --git a/doc/intro.texi b/doc/intro.texi index 6ee7ef9..94a1bd6 100644 --- a/doc/intro.texi +++ b/doc/intro.texi @@ -210,7 +210,7 @@ are not very useful for our purposes. (If no window appeared at all, and you just got a terminal full of corrupt-looking text, then you're probably logged in remotely and X forwarding is not set up correctly. In this case, you can fix your X -setup, or you can use the @option{-nv} option.) +setup, or you can use the @option{nv} option.) The text printed by Pintos inside Bochs probably went by too quickly to read. However, you've probably noticed by now that the same text @@ -227,9 +227,9 @@ options. You can select a simulator other than Bochs, although the Leland systems only have Bochs installed. You can start the simulator running a debugger (@pxref{i386-elf-gdb}). You can set the amount of memory to give the VM. Finally, you can set up how you want VM output -to be displayed: use @option{-nv} to turn off the VGA display, +to be displayed: use @option{-v} to turn off the VGA display, @option{-t} to use your terminal window as the VGA display instead of -opening a new window, or @option{-ns} to suppress the serial output to +opening a new window, or @option{-s} to suppress the serial output to @code{stdout}. The @command{pintos} program offers commands other than @samp{run} and diff --git a/doc/pintos-t2h.init b/doc/pintos-t2h.init new file mode 100644 index 0000000..064e25a --- /dev/null +++ b/doc/pintos-t2h.init @@ -0,0 +1,16 @@ +sub T2H_InitGlobals +{ + # Set the default body text, inserted between + $T2H_BODYTEXT = ''; + # text inserted after + $T2H_AFTER_BODY_OPEN = ''; + #text inserted before + $T2H_PRE_BODY_CLOSE = ''; + # this is used in footer + $T2H_ADDRESS = "$T2H_USER " if $T2H_USER; + $T2H_ADDRESS .= "on $T2H_TODAY"; + # this is added inside after and some META NAME stuff + # can be used for <style> <script>, <meta> tags + $T2H_EXTRA_HEAD = "<LINK REL=\"stylesheet\" HREF=\"pintos.css\">"; +} +1; diff --git a/doc/pintos.css b/doc/pintos.css new file mode 100644 index 0000000..b00c2ce --- /dev/null +++ b/doc/pintos.css @@ -0,0 +1,128 @@ +body { + background: white; + color: black; + padding: 0em 12em 0em 3em; + margin: 0 +} +body>p { + margin: 0pt 0pt 0pt 0em +} +body>p + p { + margin: .75em 0pt 0pt 0pt +} +H1 { + font-size: 150%; + margin-left: -1.33em +} +H2 { + font-size: 125%; + font-weight: bold; + margin-left: -.8em +} +H3 { + font-size: 100%; + font-weight: bold; + margin-left: -.5em } +H4 { + font-size: 100%; + margin-left: 0em +} +H1, H2, H3, H4, H5, H6 { + font-family: sans-serif; + color: blue +} +html { + margin: 0 +} +code { + font-family: sans-serif +} + +a:link { + color: blue; + text-decoration: none; +} +a:visited { + color: gray; + text-decoration: none; +} +a:active { + color: black; + text-decoration: none; +} +a:hover { + text-decoration: underline +} + +div.menu { + margin: 0; + font-size: 80%; + font-weight: bold; + line-height: 1.1; + text-align: center; + position: absolute; + top: 2em; + left: auto; + width: 8.5em; + right: 2em; +} +div.menu p, span.menuitem { + display: block; + margin: 0; + padding: 0.3em 0.4em; + font-family: Arial, sans-serif; + background: #ddd; + border: thin outset #000; + color: #000; + text-indent: 0em; +} +IMG.menuimg { + width: 50%; + height: auto; + border-width: 0 +} + +div.menu a, div.menu em { + display: block; + margin: 0 0.5em +} +div.menu a, div.menu em { + border-top: 2px groove #000 +} +div.menu a:first-child { + border-top: none +} +div.menu em { + color: #fff +} + +div.menu a:link { + text-decoration: none; + color: blue +} +div.menu a:visited { + text-decoration: none; + color: gray +} +div.menu a:hover { + background: blue; + color: white +} + +div.menu span.menugap + span.menuitem { + display: block; + margin-top: 1em +} + +span.hide { + display: none +} + +body>div.menu { + position: fixed +} + +address { + font-size: 90%; + font-style: normal +} diff --git a/doc/threads.texi b/doc/threads.texi index 3cb049a..451eff8 100644 --- a/doc/threads.texi +++ b/doc/threads.texi @@ -471,6 +471,18 @@ problems. There are other, equally correct solutions that do not require interrupt manipulation. However, if you do manipulate interrupts and @strong{correctly and fully document it} in your design document, we will allow limited use of interrupt disabling. + +@item +@b{What does ``warning: no previous prototype for `@var{function}'' +mean?} + +It means that you defined a non-@code{static} function without +preceding it by a prototype. Because non-@code{static} functions are +intended for use by other @file{.c} files, for safety they should be +prototyped in a header file included before their definition. To fix +the problem, add a prototype in a header file that you include, or, if +the function isn't actually used by other @file{.c} files, make it +@code{static}. @end enumerate @item Alarm Clock FAQs diff --git a/doc/userprog.texi b/doc/userprog.texi index a729418..1e18511 100644 --- a/doc/userprog.texi +++ b/doc/userprog.texi @@ -529,9 +529,9 @@ Each character is 1 byte. @end itemize @item -@b{Why doesn't keyboard input work with @option{-nv}?} +@b{Why doesn't keyboard input work with @option{-v}?} -Serial input isn't implemented. Don't use @option{-nv} if you want to +Serial input isn't implemented. Don't use @option{-v} if you want to use the shell or otherwise type at the keyboard. @end enumerate diff --git a/doc/vm.texi b/doc/vm.texi index fa511cd..299eea1 100644 --- a/doc/vm.texi +++ b/doc/vm.texi @@ -46,13 +46,13 @@ Your submission should define @code{THREAD_JOIN_IMPLEMENTED} in It is important for you to note that in addition to getting virtual memory working, this assignment is also meant to be an open-ended design problem. We will expect you to come up with a design that -makes sense. You will have the freedom to choose how to do software -translation on TLB misses, how to represent the swap partition, how to -implement paging, etc. In each case, we will expect you to provide a -defensible justification in your design documentation as to why your -choices are reasonable. You should evaluate your design on all the -available criteria: speed of handling a page fault, space overhead in -memory, minimizing the number of page faults, simplicity, etc. +makes sense. You will have the freedom to choose how to handle page +faults, how to organize the swap disk, how to implement paging, etc. +In each case, we will expect you to provide a defensible justification +in your design documentation as to why your choices are reasonable. +You should evaluate your design on all the available criteria: speed +of handling a page fault, space overhead in memory, minimizing the +number of page faults, simplicity, etc. In keeping with this, you will find that we are going to say as little as possible about how to do things. Instead we will focus on what end @@ -304,29 +304,22 @@ any implementation you like, as long as it accomplishes the goal. @node Problem 3-2 Paging To and From Disk @section Problem 3-2: Paging To and From Disk -Implement paging to and from disk. +Implement paging to and from files and the swap disk. You may use the +disk on interface @code{hd1:1} as the swap disk. You will need routines to move a page from memory to disk and from -disk to memory. You may use the Pintos file system for swap space, or -you may use the disk on interface @code{hd1:1}, which is otherwise -unused. A swap disk can theoretically be faster than using the file -system, because it avoid file system overhead and because the swap -disk and file system disk will be on separate hard disk controllers. -You will definitely need to be able to retrieve pages from files in -any case, so to avoid special cases it may be easier to use a file for -swap. You will still be using the basic file system provided with -Pintos. If you do everything correctly, your VM should still work -when you implement your own file system for the next assignment. +disk to memory, where ``disk'' is either a file or the swap disk. If +you do everything correctly, your VM should still work when you +implement your own file system for the next assignment. You will need a way to track pages which are used by a process but which are not in physical memory, to fully handle page faults. Pages -that you store on disk should not be constrained to be in sequential -order, and consequently your swap file (or swap disk) should not -require unused empty space. You will also need a way to track all of -the physical memory pages, in order to find an unused one when needed, -or to evict a page when memory is needed but no empty pages are -available. The data structures that you designed in part 1 should do -most of the work for you. +that you write to swap should not be constrained to be in sequential +order. You will also need a way to track all of the physical memory +pages, in order to find an unused one when needed, or to evict a page +when memory is needed but no empty pages are available. The data +structures that you designed in part 1 should do most of the work for +you. You will need a page replacement algorithm. The hardware sets the accessed and dirty bits when it accesses memory. Therefore, you @@ -503,17 +496,10 @@ the linker manual, accessible via @samp{info ld}. @item Page Table Management FAQs @enumerate 1 @item -@b{How do we manage allocation of pages used for page tables?} +@b{Do page tables need to created lazily?} -You can use any reasonable algorithm to do so. However, you should -make sure that memory used for page tables doesn't grow so much that -it encroaches deeply on the memory used for data pages. - -Here is one reasonable algorithm. At OS boot time, reserve some fixed -number of pages for page tables. Then, each time a new page table -page is needed, select one of these pages in ``round robin'' fashion. -If the page in use, clean up any pointers to it. Then use it for the -new page table page. +No. You can create the page tables at load time (or @code{mmap} time) +if you like. @item @b{Our code handles the PageFault exceptions. However, the number of @@ -530,11 +516,23 @@ you handle a page fault in your code. @enumerate 1 @item -@b{Can we assume (and enforce) that the user's stack will -never increase beyond one page?} +@item +@b{Does the virtual memory system need to support growth of the stack +segment?} + +Yes. If a page fault appears just below the last stack segment page, +you must add a new page to the bottom of the stack. It is impossible +to predict how large the stack will grow at compile time, so we must +allocate pages as necessary. You should only allocate additional pages +if they ``appear'' to be stack accesses. + +@item +@b{Does the first stack page need to be loaded lazily?} -No. This value was useful for project 2, but for this assignment, you -need to implement an extensible stack segment. +No, you can initialize the first stack page with the command line at +load time. There's no need to wait for it to be faulted in. Even if +you did wait, the very first instruction in the user program is likely +to be one that faults in the page. @item @b{Does the virtual memory system need to support growth of the data @@ -547,16 +545,6 @@ Implementing @code{sbrk()} has been an extra-credit assignment in previous years, but adds little additional complexity to a well-designed system. -@item -@b{Does the virtual memory system need to support growth of the stack -segment?} - -Yes. If a page fault appears just below the last stack segment page, -you must add a new page to the bottom of the stack. It is impossible -to predict how large the stack will grow at compile time, so we must -allocate pages as necessary. You should only allocate additional pages -if they ``appear'' to be stack accesses. - @item @b{But what do you mean by ``appear'' to be stack accesses? How big can a stack growth be? Under what circumstances do we grow the stack?} @@ -679,3 +667,5 @@ No, once created the mapping is valid until @code{munmap} is called or the process exits. @end enumerate @end enumerate + +TLB invalidation FIXME -- 2.30.2