#
#  $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.