->> Describe your code for reading and writing user data from the kernel.
-
->> Suppose a system call causes a full page (4,096 bytes) of data to be
->> copied from user space into the kernel. What is the least and the
->> greatest possible number of inspections of the page table (e.g. calls
->> to pagedir_get_page()) that might result? What about for a system
->> call that only copies 2 bytes of data? Is there room for improvement
->> in these numbers, and how much?
-
->> Briefly describe your implementation of the "wait" system call and how
->> it interacts with process termination.
-
->> Any access to user program memory at a user-specified address can fail
->> due to a bad pointer value. Such accesses must cause the process to
->> be terminated. System calls are fraught with such accesses, e.g. a
->> "write" system call requires reading the system call number from the
->> user stack, then each of the call's three arguments, then an arbitrary
->> amount of user memory, and any of these can fail at any point. This
->> poses a design and error-handling problem: how do you best avoid
->> obscuring the primary function of code in a morass of error-handling?
->> Furthermore, when an error is detected, how do you ensure that all
->> temporarily allocated resources (locks, buffers, etc.) are freed? In
->> a few paragraphs, describe the strategy or strategies you adopted for
+>> B3: Describe your code for reading and writing user data from the
+>> kernel.
+
+>> B4: Suppose a system call causes a full page (4,096 bytes) of data
+>> to be copied from user space into the kernel. What is the least
+>> and the greatest possible number of inspections of the page table
+>> (e.g. calls to pagedir_get_page()) that might result? What about
+>> for a system call that only copies 2 bytes of data? Is there room
+>> for improvement in these numbers, and how much?
+
+>> B5: Briefly describe your implementation of the "wait" system call
+>> and how it interacts with process termination.
+
+>> B6: Any access to user program memory at a user-specified address
+>> can fail due to a bad pointer value. Such accesses must cause the
+>> process to be terminated. System calls are fraught with such
+>> accesses, e.g. a "write" system call requires reading the system
+>> call number from the user stack, then each of the call's three
+>> arguments, then an arbitrary amount of user memory, and any of
+>> these can fail at any point. This poses a design and
+>> error-handling problem: how do you best avoid obscuring the primary
+>> function of code in a morass of error-handling? Furthermore, when
+>> an error is detected, how do you ensure that all temporarily
+>> allocated resources (locks, buffers, etc.) are freed? In a few
+>> paragraphs, describe the strategy or strategies you adopted for