-You'll need to consider this when deciding your @code{struct inode}
-organization.
-@end enumerate
-
-@node Problem 4-3 Subdirectory FAQ
-@subsection Problem 4-3: Subdirectory FAQ
-
-@enumerate 1
-@item
-@b{What's the answer to the question in the spec about why
-@command{ls} and @command{mkdir} are user programs, while @command{cd}
-is a shell command?}
-
-Each process maintains its own current working directory, so it's much
-easier to change the current working directory of the shell process if
-@command{cd} is implemented as a shell command rather than as another
-user process. In fact, Unix-like systems don't provide any way for
-one process to change another process's current working directory.
-
-@item
-@b{When the spec states that directories should be able to grow beyond
-ten files, does this mean that there can still be a set maximum number
-of files per directory that is greater than ten, or should directories
-now support unlimited growth (bounded by the maximum supported file
-size)?}
-
-We're looking for directories that can support arbitrarily large
-numbers of files. Now that directories can grow, we want you to
-remove the concept of a preset maximum file limit.
-
-@item
-@b{When should the @code{lsdir} system call return?}
-
-The @code{lsdir} system call should not return until after the
-directory has been printed. Here's a code fragment, and the desired
-output:
-
-@example
-printf ("Start of directory\n");
-lsdir ();
-printf ("End of directory\n");
-@end example
-
-This code should create the following output:
-
-@example
-Start of directory
-... directory contents ...
-End of directory
-@end example
-
-@item
-@b{Do we have to implement both absolute and relative pathnames?}
-
-Yes. Implementing @file{.} and @file{..} is extra credit, though.
-
-@item
-@b{Should @func{remove} also be able to remove directories?}
-
-Yes. The @code{remove} system call should handle removal of both
-regular files and directories. You may assume that directories can
-only be deleted if they are empty, as in Unix.
-@end enumerate
-
-@node Problem 4-4 Buffer Cache FAQ
-@subsection Problem 4-4: Buffer Cache FAQ
-
-@enumerate 1
-@item
-@b{We're limited to a 64-block cache, but can we also keep a copy of
-each @code{struct inode} for an open file inside @code{struct file},
-the way the stub code does?}
-
-No, you shouldn't keep any disk sectors stored anywhere outside the
-cache. That means you'll have to change the way the file
-implementation accesses its corresponding inode right now, since it
-currently just creates a new @code{struct inode} in its constructor
-and reads the corresponding sector in from disk when it's created.
-
-There are two reasons for not storing inodes in @code{struct file}.
-First, keeping extra copies of inodes would be cheating the 64-block
-limitation that we place on your cache. Second, if two processes have
-the same file open, you will create a huge synchronization headache
-for yourself if each @code{struct file} has its own copy of the inode.
-
-Note that you can store pointers to inodes in @code{struct file} if
-you want, and you can store some other small amount of information to
-help you find the inode when you need it.
-
-Similarly, if you want to store one block of data plus some small
-amount of metadata for each of your 64 cache entries, that's fine.
-
-@item
-@b{But why can't we store copies of inodes in @code{struct file}? We
-don't understand the answer to the previous question.}
-
-The issue regarding storing @code{struct inode}s has to do with
-implementation of the buffer cache. Basically, you can't store a
-@code{struct inode *} in @code{struct inode}. Each time you need
-to read a @code{struct inode}, you'll have to get it either from the
-buffer cache or from disk.
-
-If you look at @func{file_read_at}, it uses the inode directly
-without having first read in that sector from wherever it was in the
-storage hierarchy. You are no longer allowed to do this. You will
-need to change @code{file_read_at} (and similar functions) so that it
-reads the inode from the storage hierarchy before using it.
-@end enumerate
+You'll need to consider this when deciding your inode organization.
+@end table
+
+@node Subdirectories FAQ
+@subsection Subdirectories FAQ
+
+@table @b
+@item How should a file name like @samp{a//b} be interpreted?
+
+Multiple consecutive slashes are equivalent to a single slash, so this
+file name is the same as @samp{a/b}.
+
+@item How about a file name like @samp{/../x}?
+
+The root directory is its own parent, so it is equivalent to @samp{/x}.
+
+@item How should a file name that ends in @samp{/} be treated?
+
+Most Unix systems allow a slash at the end of the name for a directory,
+and reject other names that end in slashes. We will allow this
+behavior, as well as simply rejecting a name that ends in a slash.
+@end table
+
+@node Buffer Cache FAQ
+@subsection Buffer Cache FAQ
+
+@table @b
+@item Can we keep a @struct{inode_disk} inside @struct{inode}?
+
+The goal of the 64-block limit is to bound the amount of cached file
+system data. If you keep a block of disk data---whether file data or
+metadata---anywhere in kernel memory then you have to count it against
+the 64-block limit. The same rule applies to anything that's
+``similar'' to a block of disk data, such as a @struct{inode_disk}
+without the @code{length} or @code{sector_cnt} members.
+
+That means you'll have to change the way the inode implementation
+accesses its corresponding on-disk inode right now, since it currently
+just embeds a @struct{inode_disk} in @struct{inode} and reads the
+corresponding sector from disk when it's created. Keeping extra
+copies of inodes would subvert the 64-block limitation that we place
+on your cache.
+
+You can store a pointer to inode data in @struct{inode}, but it you do
+so you should carefully make sure that this does not limit your OS to 64
+simultaneously open files.
+You can also store other information to help you find the inode when you
+need it. Similarly, you may store some metadata along each of your 64
+cache entries.
+
+You can keep a cached copy of the free map permanently in memory if you
+like. It doesn't have to count against the cache size.
+
+@func{byte_to_sector} in @file{filesys/inode.c} uses the
+@struct{inode_disk} directly, without first reading that sector from
+wherever it was in the storage hierarchy. This will no longer work.
+You will need to change @func{inode_byte_to_sector} to obtain the
+@struct{inode_disk} from the cache before using it.
+@end table