-Added IRQ to PCI

[pintos-anon] / doc / standards.texi

diff --git a/doc/standards.texi b/doc/standards.texi
index 7af266e9c10b9cecb5be44f8ae190acf9a8048ef..162ec44ecfde7f06cb4dacd851b991b39dd88c89 100644 (file)
--- a/doc/standards.texi
+++ b/doc/standards.texi
@@ -39,58 +39,31 @@ follows the @uref{http://www.gnu.org/prep/standards_toc.html, , GNU
 Coding Standards}.  We encourage you to follow the applicable parts of
 them too, especially chapter 5, ``Making the Best Use of C.''  Using a
 different style won't cause actual problems, but it's ugly to see
-gratuitous differences in style from one function to another.
+gratuitous differences in style from one function to another.  If your
+code is too ugly, it will cost you points.
 
-Pintos comments sometimes refer to outside standards or
+Please limit C source file lines to at most 79 characters long.
+
+Pintos comments sometimes refer to external standards or
 specifications by writing a name inside square brackets, like this:
 @code{[IA32-v3]}.  These names refer to the reference names used in
 this documentation (@pxref{References}).
 
-@node Conditional Compilation
-@section Conditional Compilation
-
-Given the scope and complexity of your assignments this quarter, you
-may find it convenient while coding and debugging (and we will find it
-convenient while grading) to be able to independently turn different
-parts of the assignments on and off.  To do this, choose a macro name
-and use it in conditional
-compilation directives, e.g.:
-
-@example
-#ifdef @var{NAME}
-@dots{}your code@dots{}
-#endif
-@end example
-
-In general, the code that you turn in must not depend on conditional
-compilation directives.  Project code should be written so that all of
-the subproblems for the project function together, and it should
-compile properly without the need for any new macros to be defined.
-There are a few exceptions:
-
-@itemize @bullet
-@item
-Problem 1-2, @func{thread_join}.  Some other code expects
-@code{THREAD_JOIN_IMPLEMENTED} to be defined once you've implemented
-this function.
-
-@item
-Problem 1-4, the advanced scheduler.  We must be able to turn this on
-and off with a compile-time directive.  You must use the macro name we
-specify for that part.  @xref{Problem 1-4 Advanced Scheduler}, for
-details.
-
-@item
-Code written for extra credit may be included conditionally.  If the
-extra credit code changes the normally expected functionality of the
-code, then it @emph{must} be included conditionally, and it must not
-be enabled by default.
-@end itemize
-
-You can use @file{constants.h} in @file{pintos/src} to define macros
-for conditional compilation.  We will replace the @file{constants.h}
-that you supply with one of our own when we test your code, so do not
-define anything important in it.
+If you remove existing Pintos code, please delete it from your source
+file entirely.  Don't just put it into a comment or a conditional
+compilation directive, because that makes the resulting code hard to
+read.  We're only going to do a compile in the directory for the current
+project, so you don't need to make sure that the previous projects also
+compile.
+
+Project code should be written so that all of the subproblems for the
+project function together, that is, without the need to rebuild with
+different macros defined, etc.  If you do extra credit work that
+changes normal Pintos behavior so as to interfere with grading, then
+you must implement it so that it only acts that way when given a
+special command-line option of the form @option{-o @var{name}}, where
+@var{name} is a name of your choice.  You can add such an option by
+modifying @func{argv_init} in @file{threads/init.c}.
 
 @node C99
 @section C99
@@ -192,7 +165,7 @@ terminator and it has performance problems besides.  Again, use
 @func{strlcpy}.
 
 @item strcat
-Same issue as @func{strcpy}, but substitute @func{strlcat}.
+Same issue as @func{strcpy}.  Use @func{strlcat} instead.
 Again, refer to comments in its source code in @code{lib/string.c} for
 documentation.