1 | # |
---|
2 | # $Id$ |
---|
3 | # |
---|
4 | |
---|
5 | This is a collection of things which need to be done to the various |
---|
6 | manuals. |
---|
7 | |
---|
8 | KA9Q |
---|
9 | ==== |
---|
10 | |
---|
11 | Outstanding questions with Eric Norum: |
---|
12 | |
---|
13 | + "Understand the KA9Q scheduling conventions" makes reference |
---|
14 | to driver tasks. Do you think a sentence or two explaining |
---|
15 | the driver tasks before going into this would be be helpful? |
---|
16 | |
---|
17 | + In "Write your driver transmit function", there is the comment |
---|
18 | "as far as I can tell". Can we make this a stronger statement. |
---|
19 | |
---|
20 | + In the section "Write your driver receive task", there is a |
---|
21 | comment indicating that a copy can be avoided if space |
---|
22 | for a pointer is left at the beginning of the mbuf's. Do |
---|
23 | we avoid this? Do we depend on the driver doing something |
---|
24 | special? How to make this happen all the time? |
---|
25 | |
---|
26 | + What do I need to do so all the BSPs can set the HeapSize like |
---|
27 | the gen68360? |
---|
28 | |
---|
29 | + In "Starting and intitializing the network tasks", |
---|
30 | step 2 says "keep in mind...". What impact does this have? |
---|
31 | |
---|
32 | + In Step 5 (bootp), how long is each of the 10 |
---|
33 | tries? Is there a built in timeout? |
---|
34 | |
---|
35 | + Syslogd questions: How often is the log written? |
---|
36 | |
---|
37 | + Do we need to document the interface to the syslogd? |
---|
38 | |
---|
39 | + How many incompatibilities are left between RTEMS/KA9Q sockets |
---|
40 | and BSD sockets? How hard are these be to fix? |
---|
41 | |
---|
42 | + What other levels could there be besides SOL_SOCKET and |
---|
43 | what do they mean? |
---|
44 | |
---|
45 | + Is there a standard naming convention for the DNS |
---|
46 | name lookup routines? |
---|
47 | |
---|
48 | + Does testdriver.c have all of the code outlined |
---|
49 | in the Driver Basic Operation section? Is it easy |
---|
50 | to go through each of the steps with this test? |
---|
51 | What is the discard port? |
---|
52 | |
---|
53 | + How can I package your network tests? |
---|
54 | |
---|
55 | + Simple server operation... after I telnet to the |
---|
56 | specified ports, what should I see if it works? |
---|
57 | |
---|
58 | + Could we include some sample output/benchmark |
---|
59 | results in the Throughput section. Ideally |
---|
60 | there would be a little information on each |
---|
61 | the system where these results were gathered. |
---|
62 | And possibily we could get results on multiple |
---|
63 | systems. |
---|
64 | |
---|
65 | + Is there a README somewhere which could be included |
---|
66 | to augment the instructions for executing the ttcp test. |
---|
67 | |
---|
68 | POSIX User Notes |
---|
69 | ================ |
---|
70 | |
---|
71 | Add pages for network services. |
---|
72 | |
---|
73 | Add timer() services if we have any. |
---|
74 | |
---|
75 | |
---|
76 | Development Environment Guide |
---|
77 | ============================= |
---|
78 | Either rename to "A Tour of the RTEMS Source Tree" or include |
---|
79 | more information on the GNU tools. |
---|
80 | |
---|
81 | The "C Suites" section is oddly named and the directory |
---|
82 | tree included is wrong in that make is no longer under |
---|
83 | the c directory. I think the build-tools make have |
---|
84 | moved as well. |
---|
85 | |
---|
86 | All the paths should be provided as relative paths |
---|
87 | from the top of the RTEMS source tree. It wastes |
---|
88 | valuable screen space to do otherwise. |
---|
89 | |
---|
90 | The last paragraph of "C Suites" is vague and could |
---|
91 | be written better. It should include the subdirectory |
---|
92 | names as part of the textual description. |
---|
93 | |
---|
94 | |
---|
95 | Should this documentation even use the phrase "C Implementation" |
---|
96 | any longer? |
---|
97 | |
---|
98 | Directory names should be in @code -- not "quoted". |
---|
99 | |
---|
100 | In "Support Library Source Directory", look for "which installed" |
---|
101 | |
---|
102 | In the latter part of the "libbsp" paragraph in "Support |
---|
103 | Library Source Directory", there is reference to the |
---|
104 | stubdr directory which is no longer there. |
---|
105 | |
---|
106 | Update this section to include discussion of the shared |
---|
107 | subdirectory and its relationship to the BSPs. Write this |
---|
108 | in such a way that it can be passed on to Geoffroy Montel. |
---|
109 | |
---|
110 | Include a better discussion of the subdirectories |
---|
111 | under each BSP. This can be a starting point for |
---|
112 | Geoffroy Montel. The sample tests also deserve mention |
---|
113 | in a BSP development guide. |
---|
114 | |
---|
115 | In the section, "Test Suite Source Directory", there is a |
---|
116 | numeric count of the number of tests in each suite. This |
---|
117 | should be eliminated for maintenance purposes. |
---|
118 | |
---|
119 | The psxtest directory is not mentioned. Check that no others |
---|
120 | have been forgotten. |
---|
121 | |
---|
122 | There should probably be no reference to the Ada sample |
---|
123 | applications. This document used to cover both implementations. |
---|
124 | This now seems inappropriate. |
---|
125 | |
---|
126 | The hello world sample test discussion mentions that it provides |
---|
127 | a rudiementary test of the BSP startup code and the "RTEMS |
---|
128 | C Library". This should be rewritten to tell mroe about what |
---|
129 | this test shows (actually a lot). It should mention that this |
---|
130 | test tries to avoid using interrupts. |
---|
131 | |
---|
132 | The ticker test should mention that in contrast to hello, it |
---|
133 | does use interrupts. :) It can be used to tune the clock |
---|
134 | tick. |
---|
135 | |
---|
136 | The ticker test documentation says it calls "tm_get" -- jeez |
---|
137 | how old is this manual. |
---|