New file.

doc/TODO

@@ -0,0 +1,137 @@
+#
+#  $Id$
+#
+
+This is a collection of things which need to be done to the various 
+manuals.
+
+KA9Q
+====
+
+Outstanding questions with Eric Norum:
+
++ "Understand the KA9Q scheduling conventions" makes reference
+  to driver tasks.  Do you think a sentence or two explaining
+  the driver tasks before going into this would be be helpful?
+
++ In "Write your driver transmit function", there is the comment
+  "as far as I can tell".  Can we make this a stronger statement.
+
++ In the section "Write your driver receive task", there is a 
+  comment indicating that a copy can be avoided if space 
+  for a pointer is left at the beginning of the mbuf's.  Do
+  we avoid this?  Do we depend on the driver doing something
+  special?  How to make this happen all the time?
+
++ What do I need to do so all the BSPs can set the HeapSize like
+  the gen68360?
+
++ In "Starting and intitializing the network tasks", 
+  step 2 says "keep in mind...".  What impact does this have?
+
++ In Step 5 (bootp), how long is each of the 10 
+  tries?  Is there a built in timeout?
+
++ Syslogd questions: How often is the log written?  
+
++ Do we need to document the interface to the syslogd?
+
++ How many incompatibilities are left between RTEMS/KA9Q sockets
+  and BSD sockets?  How hard are these be to fix?  
+
++ What other levels could there be besides SOL_SOCKET and
+  what do they mean?
+
++ Is there a standard naming convention for the DNS
+  name lookup routines?
+
++ Does testdriver.c have all of the code outlined
+  in the Driver Basic Operation section?  Is it easy
+  to go through each of the steps with this test?
+  What is the discard port?
+
++ How can I package your network tests? 
+
++ Simple server operation... after I telnet to the
+  specified ports, what should I see if it works?
+
++ Could we include some sample output/benchmark
+  results in the Throughput section.  Ideally
+  there would be a little information on each
+  the system where these results were gathered.
+  And possibily we could get results on multiple
+  systems.
+
++ Is there a README somewhere which could be included
+  to augment the instructions for executing the ttcp test.
+
+POSIX User Notes
+================
+
+Add pages for network services.
+
+Add timer() services if we have any.
+
+
+Development Environment Guide
+=============================
+Either rename to "A Tour of the RTEMS Source Tree" or include
+more information on the GNU tools.  
+
+The "C Suites" section is oddly named and the directory
+tree included is wrong in that make is no longer under
+the c directory.  I think the build-tools make have
+moved as well.
+
+All the paths should be provided as relative paths
+from the top of the RTEMS source tree.  It wastes
+valuable screen space to do otherwise.
+
+The last paragraph of "C Suites" is vague and could
+be written better.  It should include the subdirectory
+names as part of the textual description.
+
+
+Should this documentation even use the phrase "C Implementation"
+any longer?
+
+Directory names should be in @code -- not "quoted".
+
+In "Support Library Source Directory", look for "which installed"
+
+In the latter part of the "libbsp" paragraph in "Support
+Library Source Directory", there is reference to the 
+stubdr directory which is no longer there.
+
+Update this section to include discussion of the shared
+subdirectory and its relationship to the BSPs.  Write this
+in such a way that it can be passed on to Geoffroy Montel.
+
+Include a better discussion of the subdirectories
+under each BSP.  This can be a starting point for
+Geoffroy Montel.  The sample tests also deserve mention
+in a BSP development guide.
+
+In the section, "Test Suite Source Directory", there is a
+numeric count of the number of tests in each suite.  This
+should be eliminated for maintenance purposes.
+
+The psxtest directory is not mentioned.  Check that no others
+have been forgotten.
+
+There should probably be no reference to the Ada sample
+applications.  This document used to cover both implementations.
+This now seems inappropriate.
+
+The hello world sample test discussion mentions that it provides
+a rudiementary test of the BSP startup code and the "RTEMS
+C Library".  This should be rewritten to tell mroe about what
+this test shows (actually a lot).  It should mention that this
+test tries to avoid using interrupts.
+
+The ticker test should mention that in contrast to hello, it
+does use interrupts. :)  It can be used to tune the clock
+tick.
+
+The ticker test documentation says it calls "tm_get" -- jeez
+how old is this manual.