summaryrefslogtreecommitdiffstats
path: root/nuttx/TODO
blob: 543d15f70747e448f3e3a39e0e4b9a40fcfa10a8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
NuttX TODO List (Last updated August 12, 2012)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This file summarizes known NuttX bugs, limitations, inconsistencies with 
standards, things that could be improved, and ideas for enhancements.

nuttx/

  (5)  Task/Scheduler (sched/)
  (1)  On-demand paging (sched/)
  (1)  Memory Managment (mm/)
  (2)  Signals (sched/, arch/)
  (2)  pthreads (sched/)
  (2)  C++ Support
  (5)  Binary loaders (binfmt/)
 (17)  Network (net/, drivers/net)
  (3)  USB (drivers/usbdev, drivers/usbhost)
 (11)  Libraries (lib/)
  (9)  File system/Generic drivers (fs/, drivers/)
  (5)  Graphics subystem (graphics/)
  (1)  Pascal add-on (pcode/)
  (1)  Documentation (Documentation/)
  (6)  Build system / Toolchains
  (5)  Linux/Cywgin simulation (arch/sim)
  (6)  ARM (arch/arm/)
  (1)  ARM/C5471 (arch/arm/src/c5471/)
  (3)  ARM/DM320 (arch/arm/src/dm320/)
  (2)  ARM/i.MX (arch/arm/src/imx/)
  (3)  ARM/LPC17xx (arch/arm/src/lpc17xx/)
  (7)  ARM/LPC214x (arch/arm/src/lpc214x/)
  (2)  ARM/LPC313x (arch/arm/src/lpc313x/)
  (0)  ARM/LPC43x (arch/arm/src/lpc43xx/)
  (3)  ARM/STR71x (arch/arm/src/str71x/)
  (3)  ARM/LM3S6918 (arch/arm/src/lm3s/)
  (7)  ARM/STM32 (arch/arm/src/stm32/)
  (3)  AVR (arch/avr)
  (0)  Intel x86 (arch/x86)
  (4)  8051 / MCS51 (arch/8051/)
  (3)  MIPS/PIC32 (arch/mips)
  (1)  Hitachi/Renesas SH-1 (arch/sh/src/sh1)
  (4)  Renesas M16C/26 (arch/sh/src/m16c)
 (10)  z80/z8/ez80 (arch/z80/)
  (8)  z16 (arch/z16/)
  (1)  mc68hc1x (arch/hc)

apps/

  (5)  Network Utilities (apps/netutils/)
  (4)  NuttShell (NSH) (apps/nshlib)
  (1)  System libraries apps/system (apps/system)
  (5)  Other Applications & Tests (apps/examples/)

o Task/Scheduler (sched/)
  ^^^^^^^^^^^^^^^^^^^^^^^

  Title:       CHILD PTHREAD TERMINATION
  Description: When a tasks exits, shouldn't all of its child pthreads also be
               terminated?
  Status:      Open
  Priority:    Medium, required for good emulation of process/pthread model.

  Title:       MMAN.H
  Description: Implement sys/mman.h and functions
  Status:      Open
  Priority:    Low

  Title:       WAIT.H
  Description: Implement sys/wait.h and functions.  Consider implementing wait,
               waitpid, waitid.  At present, a parent has no information about
               child tasks.

               Update: A simple but usable version of waitpid() has been included.
               This version is not compliant with all specifications and can be
               enabled with CONFIG_SCHED_WAITPID. 
  Status:      Open
  Priority:    Low

  Title:       MISSING ERRNO SETTINGS
  Description: Several APIs do not set errno.  Need to review all APIs.
               Update:  These are being fixed as they are encountered.  There is
               no accounting of how many interfaces have this problem.
  Status:      Open
  Priority:    Medium, required for standard compliance (but makes the
               code bigger)

  Title:       TICKLESS OS
  Description: On a side note, I have thought about a tick-less timer for the OS
               for a long time.  Basically we could replace the periodic system
               timer interrupt with a one-shot interval timer programmed for the
               next interesting event time.  That is one way to both reduce the
               timer interrupt overhead and also to increase the accuracy of
               delays.

               Current timer processing is in sched/sched_processtimer.c:

               1) Calls clock_timer() which just increments a counter (the system
                  timer -- basically "up-time"). This is only used when code asks
                  for the current time.  In a tickless OS, some substitute answer
                  for the question "What time is it?" would need to be developed.
                  You could use an RTC? Or maybe logic that gets the time until the
                  next interval expiration and computes the current time. The
                  solution is not too difficult, but depends on a hardware solution.

               2) Calls wd_timer() which handles the link list of ordered events:
                  Each timer event is saved with the delta time to the next event
                  in the list. So an interval timer would be perfect to implement this.

               3) sched_process_timeslice(). Then there is round-robin time-slicing.

  Status:      Open
  Priority:    Low

o On-demand paging (sched/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       ON-DEMAND PAGE INCOMPLETE
  Description: On-demand paging has recently been incorporated into the RTOS.
               The design of this feature is described here:
               http://www.nuttx.org/NuttXDemandPaging.html.
               As of this writing, the basic feature implementation is
               complete and much of the logic has been verified.  The test
               harness for the feature exists only for the NXP LPC3131 (see
               configs/ea3131/pgnsh and locked directories).  There are
               some limitations of this testing so I still cannot say that
               the feature is fully functional.
  Status:      Open
  Priority:    Medium-Low

o Other core OS logic
  ^^^^^^^^^^^^^^^^^^^

  Title:       GET_ENVIRON_PTR()
  Description: get_environ_ptr() (sched/sched_getenvironptr.c) is not implemented.
               The representation of the the environment strings selected for
               NutX is not compatible with the operation.  Some significant
               re-design would be required to implement this funcion and that
               effort is thought to be not worth the result.
  Status:      Open
  Priority:    Low -- There is no plan to implement this.

  Title:       TIMER_GETOVERRUN()
  Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
  Status:      Open
  Priority:    Low -- There is no plan to implement this.

o Memory Managment (mm/)
  ^^^^^^^^^^^^^^^^^^^^^^

  Title:       FREE MEMORY ON TASK EXIT
  Description: Add an option to free all memory allocated by a task when the
               task exits. This is probably not be worth the overhead for a
               deeply embedded system.

               There would be complexities with this implementation as well
               because often one task allocates memory and then passes the
               memory to another:  The task that "owns" the memory may not
               be the same as the task that allocated the memory.

               Update.  From the NuttX forum:
               ...there is a good reason why task A should never delete task B.
               That is because you will strand memory resources. Another feature
               lacking in most flat address space RTOSs is automatic memory
               clean-up when a task exits.

               That behavior just comes for free in a process-based OS like Linux:
               Each process has its own heap and when you tear down the process
               environment, you naturally destroy the heap too.

               But RTOSs have only a single, shared heap. I have spent some time
               thinking about how you could clean up memory required by a task
               when a task exits. It is not so simple. It is not as simple as
               just keeping memory allocated by a thread in a list then freeing
               the list of allocations when the task exists.

               It is not that simple because you don't know how the memory is
               being used. For example, if task A allocates memory that is used
               by task B, then when task A exits, you would not want to free that
               memory needed by task B. In a process-based system, you would
               have to explicitly map shared memory (with reference counting) in
               order to share memory. So the life of shared memory in that
               environment is easily managed.

               I have thought that the way that this could be solved in NuttX
               would be: (1) add links and reference counts to all memory allocated
               by a thread. This would increase the memory allocation overhead!
               (2) Keep the list head in the TCB, and (3) extend mmap() and munmap()
               to include the shared memory operations (which would only manage
               the reference counting and the life of the allocation).

               Then what about pthreads? Memory should not be freed until the last
               pthread in the group exists. That could be done with an additional
               reference count on the whole allocated memory list (just as streams
               and file descriptors are now shared and persist until the last
               pthread exits).

               I think that would work but to me is very unattractive and
               inconsistent with the NuttX "small footprint" objective. ...

               Other issues:
               - Memory free time would go up because you would have to remove
                 the memory from that list in free().
               - There are special cases inside the RTOS itself.  For example,
                 if task A creates task B, then initial memory allocations for
                 task B are created by task A.  Some special allocators would
                 be required to keep this memory on the correct list (or on
                 no list at all).

  Status:      Open
  Priority:    Medium/Low, a good feature to prevent memory leaks but would
               have negative impact on memory usage and code size.

o Signals (sched/, arch/)
  ^^^^^^^^^^^^^^^^^^^^^^^

  Title:       STANDARD SIGNALS
  Description: 'Standard' signals and signal actions are not supported.
               (e.g., SIGINT, SIGCHLD, SIGSEGV, etc).
  Status:      Open
  Priority:    Low, required by standards but not so critical for an
               embedded system.

  Title:       SIGEV_THREAD
  Description: sig_notify() logic does not support SIGEV_THREAD; structure
               struct sigevent does not provide required members sigev_notify_function
               or sigev_notify_attributes.
  Status:      Low, there are alternative designs.  However, these features
               are required by the POSIX standard.
  Priority:    Low for now

o pthreads (sched/)
  ^^^^^^^^^^^^^^^^^

  Title:       CANCELLATION POINTS
  Description: pthread_cancel():  Should implement cancellation points and
               pthread_testcancel()
  Status:      Open
  Priority:    Low, probably not that useful

  Title:       PTHREAD_PRIO_PROTECT
  Description:  Extended pthread_mutexattr_setprotocol() suport PTHREAD_PRIO_PROTECT:
               "When a thread owns one or more mutexes initialized with the
               PTHREAD_PRIO_PROTECT protocol, it shall execute at the higher of its
               priority  or  the  highest  of the priority ceilings of all the mutexes
               owned by this thread and initialized with this attribute, regardless of
               whether other threads are blocked on any of these mutexes or not.

               "While  a  thread is holding a mutex which has been initialized with
               the PTHREAD_PRIO_INHERIT or PTHREAD_PRIO_PROTECT protocol attributes,
               it shall not be subject to being moved to the tail of the scheduling queue
               at its priority in the event that its original priority is changed,
               such as by a call to sched_setparam(). Likewise, when a thread unlocks
               a mutex that has been initialized with the PTHREAD_PRIO_INHERIT or
               PTHREAD_PRIO_PROTECT protocol attributes, it shall not be subject to
               being moved to the tail of the scheduling queue at its priority in  the
               event that its original priority is changed."
  Status:      Open
  Priority:    Low -- about zero, probably not that useful. Priority inheritance is
               already supported and is a much better solution.  And it turns out
               that priority protection is just about as complex as priority inheritance.
               Exerpted from my post in a Linked-In discussion:

               "I started to implement this HLS/"PCP" semaphore in an RTOS that I
               work with (http://www.nuttx.org) and I discovered after doing the
               analysis and basic code framework that a complete solution for the
               case of a counting semaphore is still quite complex -- essentially
               as complex as is priority inheritance.

               "For example, suppose that a thread takes 3 different HLS semaphores
               A, B, and C. Suppose that they are prioritized in that order with
               A the lowest and C the highest. Suppose the thread takes 5 counts
               from A, 3 counts from B, and 2 counts from C. What priority should
               it run at? It would have to run at the priority of the highest
               priority semaphore C. This means that the RTOS must maintain
               internal information of the priority of every semaphore held by
               the thread.

               "Now suppose it releases one count on semaphore B. How does the
               RTOS know that it still holds 2 counts on B? With some complex
               internal data structure. The RTOS would have to maintain internal
               information about how many counts from each semaphore are held
               by each thread.

               "How does the RTOS know that it should not decrement the priority
               from the priority of C? Again, only with internal complexity. It
               would have to know the priority of every semaphore held by
               every thread.

               "Providing the HLS capability on a simple phread mutex would not
               be such quite such a complex job if you allow only one mutex per
               thread. However, the more general case seems almost as complex
               as priority inheritance. I decided that the implementation does
               not have value to me. I only wanted it for its reduced
               complexity; in all other ways I believe that it is the inferior
               solution. So I discarded a few hours of programming. Not a
               big loss from the experience I gained."

o C++ Support
  ^^^^^^^^^^^

  Title:       USE OF SIZE_T IN NEW OPERATOR
  Description: The argument of the 'new' operators should take a type of
               size_t (see libxx/libxx_new.cxx and libxx/libxx_newa.cxx).  But
               size_t has an unknown underlying.  In the nuttx sys/types.h
               header file, size_t is typed as uint32_t (which is determined by
               architecture-specific logic).  But the C++ compiler may believe
               that size_t is of a different type resulting in compilation errors
               in the operator.  Using the underlying integer type Instead of
               size_t seems to resolve the compilation issues.
  Status:      Kind of open.  There is a workaround.  Setting CONFIG_CXX_NEWLONG=y
               will define the operators with argument of type unsigned long;
               Setting CONFIG_CXX_NEWLONG=n will define the operators with argument
               of type unsigned int.  But this is pretty ugly!  A better solution
               would be to get ahold of the compilers definition of size_t.
  Priority:    Low.

  Title:       STATIC CONSTRUCTORS
  Description: Need to call static constructors
               Update:  Static constructors are implemented for the STM32 F4 and
               this will provide the model for all solutions.  Basically, if
               CONFIG_HAVE_CXXINITIALIZE=y is defined in the configuration, then
               board-specific code must provide the interface up_cxxinitialize().
               up_cxxinitialize() is called from user_start() to initialize
               all static class instances.  This TODO item probably has to stay
               open because this solution is only available on STM32 F4.
  Status:      Open
  Priority:    Low, depends on toolchain.  Call to gcc's built-in static
               constructor logic will probably have to be performed by
               user logic in user_start().

o Binary loaders (binfmt/)
  ^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       NXFLAT TESTS
  Description: Not all of the NXFLAT test under apps/examples/nxflat are working.
               Most simply do not compile yet.  tests/mutex runs okay but
               outputs garbage on completion.
  Status:      Open
  Priority:    High

  Title:       ARM UP_GETPICBASE()
  Description: The ARM up_getpicbase() does not seem to work.  This means
               the some features like wdog's might not work in NXFLAT modules.
  Status:      Open
  Priority:    Medium-High

  Title:       READ-ONLY DATA IN RAM
  Description: At present, all .rodata must be put into RAM.  There is a 
               tentative design change that might allow .rodata to be placed
               in FLASH (see Documentation/NuttXNxFlat.html).
  Status:      Open
  Priority:    Medium

  Title:       GOT-RELATIVE FUNCTION POINTERS
  Description: If the function pointer to a statically defined function is
               taken, then GCC generates a relocation that cannot be handled
               by NXFLAT.  There is a solution described in Documentataion/NuttXNxFlat.html,
               by that would require a compiler change (which we want to avoid).
               The simple workaround is to make such functions global in scope.
  Status:      Open
  Priority:    Low (probably will not fix)

  Title:       USE A HASH INSTEAD OF A STRING IN SYMBOL TABLES
  Description: In the NXFLAT symbol tables... Using a 32-bit hash value instead
               of a string to identify a symbol should result in a smaller footprint.
  Status:      Open
  Priority:    Low

  Title:       WINDOWS-BASED TOOLCHAIN BUILD
  Description: Windows build issue.  Some of the configurations that use NXFLAT have
               the linker script specified like this:

               NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld -no-check-sections

               That will not work for windows-based tools because they require Windows
               style paths.  The solution is to do something like this:

               if ($(WINTOOL)y)
                 NXFLATLDSCRIPT=${cygpath -w $(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld}
               else
                 NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat.ld
               endif
               
               Then use
               
               NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T"$(NXFLATLDSCRIPT)" -no-check-sections

  Status:      Open
  Priority:    There are too many references like the above.  They will have
               to get fixed as needed for Windows native tool builds.

o Network (net/, drivers/net)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       SOCK_RAW/SOCK_PACKET
  Description: Should implement SOCK_RAW, SOCK_PACKET
  Status:      Open
  Priority:    Low

  Tile:        MULTIPLE NETWORK INTERFACE SUPPORT
  Description: uIP polling issues / Multiple network interface support:
               (1) Current logic will not support multiple ethernet drivers.
                  Each driver should poll on TCP connections connect on the
                  network supported by the driver; UDP polling should respond
                  with TX data only if the UDP packet is intended for the
                  the network supported by the driver.
               (2) If there were multiple drivers, polling would occur at
                  double the rate.  Fix by using bound IP address in TCP
                  connection (lipaddr) and verifying that it is in the subnet
                  served by the driver.
  Status:      Open
  Priority:    Medium, The feature is not important, but it is important
               for NuttX to resolve the architectural issues.

  Title:       SENDTO() AND MULTIPLE NETWORK INTERFACE SUPPORT
  Description: sendto() and multiple network interface support:
               When polled, would have to assure that the destination IP
               is on the subnet served by the polling driver.
  Status:      Open
  Priority:    Medium, The feature is not important, but it is important
               for NuttX to resolve the architectural issues.

  Title:       IPv6
  Description: IPv6 support is incomplete.  Adam Dunkels has recently announced
               IPv6 support for uIP (currently only as part of Contiki).  Those
               changes need to be ported to NuttX.
  Status:      Open
  Priority:    Medium

  Title:       LISTENING FOR UDP BROADCASTS
  Description: Incoming UDP broadcast should only be accepted if listening on
               INADDR_ANY(?)
  Status:      Open
  Priority:    Low

  Title:       READ-AHEAD THROTTLING
  Description: Read-ahead buffers capture incoming TCP data when no user
               thread is recv-ing the data.  Should add some driver call to
               support throttling; when there is no listener for new data, the
               driver should be throttled.  Perhaps the driver should disable
               RX interrupts when throttled and re-anable on each poll time.
               recvfrom would, of course, have to un-throttle.
  Status:      Open
  Priority:    Medium

  Title:       STANDARDIZE ETHERNET DRIVER STATISTICS
  Description: Need to standardize collection of statistics from network
               drivers.  apps/nshlib ifconfig command should present
               statistics.
  Status:      Open
  Priority:    Low

  Title:       CONCURRENT TCP SEND OPERATIONS
  Description: At present, there cannot be two concurrent active TCP send
               operations in progress using the same socket.  This is because
               the uIP ACK logic will support only one transfer at a time.  The
               solution is simple: A mutex will be needed to make sure that each 
               send that is started is able to be the exclusive sender until all of
               the data to be sent has been ACKed.
  Status:      Open.  There is some temporary logic to apps/nshlib that does
               this same fix and that temporary logic should be removed when
               send() is fixed.
  Priority:    Medium-Low.  This is an important issue for applications that
               send on the same TCP socket from multiple threads.

  Title:       UDP READ-AHEAD?
  Description: TCP supports read-ahead buffering to handle the receipt of
               TCP/IP packets when there is no read() in place.  Should such
               capability be useful for UDP?  PRO: Would reduce packet loss
               and enable support for poll()/select().  CON: UDP is inherently
               lossy so why waste memory footprint?
  Status:      Open
  Priority:    Medium

  Title:       NO POLL/SELECT ON UDP SOCKETS
  Description: poll()/select() is not implemented for UDP sockets because they do
               do not support read-ahead buffering.  Therefore, there is never
               a case where you can read from a UDP socket without blocking.
  Status:      Open, depends on UDP read-ahead support
  Priority:    Medium

  Title:       POLL/SELECT ON TCP SOCKETS NEEDS READ-AHEAD
  Description: poll()/select() only works for availability of buffered TCP
               read data (when read-ahead is enabled).  The way writing is
               handled in uIP, all sockets must wait when send and cannot
               be notifiied when they can send without waiting.
  Status:      Open, probably will not be fixed.
  Priority:    Medium... this does effect porting of applications that expect
               different behavior from poll()/select()

  Title:       SOCKETS DO NOT ALWAYS SUPPORT O_NONBLOCK
  Description: sockets do not support all modes for O_NONBLOCK. Sockets
               support only (1) TCP/IP non-blocking read operations when read-ahead
               buffering is enabled, and (2) TCP/IP accept() operations when TCP/IP
               connection backlog is enabled.
  Status:      Open
  Priority:    Low.

  Title:       UNFINISHED CRYSTALLAN CS89X0 DRIVER
  Description: I started coding a CrystalLan CS89x0 driver (drivers/net/cs89x0.c),
               but never finished it.
  Status:      Open
  Priority:    Low unless you need it.

  Title:       UNTESTED IGMPv2
  Description: Support for client-side IGMPv2 multicast has been added but not yet
               tested (because I don't have a proper environment for multicast testing).
               There are most likely errors that need to be fixed at least in the
               receipt of multicast packets.

               In addition, an ethernet driver that needs to work with the IGMP logic
               will have to include additional support for multicast MAC address tables.
  Status:      Open
  Priority:    Low unless you need it.

  Title:       INTERFACES TO LEAVE/JOIN IGMP MULTICAST GROUP
  Description: The interfaces used to leave/join IGMP multicast groups is non-standard.
               RFC3678 (IGMPv3) suggests ioctl() commands to do this (SIOCSIPMSFILTER) but
               also status that those APIs are historic.  NuttX implements these ioctl
               commands, but is non-standard because:  (1) It does not support IGMPv3, and
               (2) it looks up drivers by their device name (eg., "eth0") vs IP address.

               Linux uses setsockopt() to control multicast group membership using the
               IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP options.  It also looks up drivers
               using IP addresses (It would require additional logic in NuttX to look up
               drivers by IP address).  See http://tldp.org/HOWTO/Multicast-HOWTO-6.html
  Status:      Open
  Priority:    Medium.  All standards compatibility is important to NuttX.  However, most
               the mechanism for leaving and joining groups is hidden behind a wrapper
               function so that little of this incompatibilities need be exposed.

  Title:       CONFIGURATIONS WITH TINY MTUS
  Description: Many configurations have the MTU (CONFIG_NET_BUFSIZE) set to very small
               numbers, less then the minimum MTU size that must be supported -- 576.
               This can cause problems in some networks:  CONFIG_NET_BUFSIZE should
               be set to at least 576 in all defconfig files.

               The symptoms of using very small MTU sizes can be very strange.  With
               Ubuntu 9.x and vsFtpd was that the total packet size did *not match* the
               packet size in the IP header.  This then caused a TCP checksum failure
               and the packet was rejected.
  Status:      Open
  Priority:    Low... fix defconfig files as necessary.

  Title:       UNFINISHED ENC28J60 DRIVER
  Description: So far, I have not come up with a usable hardware platform to
               verify the ENC28J60 Ethernet driver (drivers/net/enc28j60.c).
               So it is untested.
  Status:      Open
  Priority:    Low unless you need it.

o USB (drivers/usbdev, drivers/usbhost)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       USB STORAGE DRIVER DELAYS
  Description: There is a workaround for a bug in drivers/usbdev/usbdev_storage.c.
               that involves delays.  This needs to be redesigned to eliminate these
               delays.  See logic conditioned on CONFIG_USBMSC_RACEWAR.
  Status:      Open
  Priority:    Medium

  Title:       RTL8187 DRIVER IS UNFINISHED
  Description: misc/drivers/usbhost_rtl8187.c is a work in progress.  There is no RTL8187
               driver available yet.  That is a work in progress it was abandoned because
               it depends on having an 802.11g stack.
  Status:      Open
  Priority:    Low (Unless you need RTL8187 support).

  Title:       EP0 OUT CLASS DATA
  Description: There is no mechanism in place to handle EP0 OUT data transfers.
               There are two aspects to this problem, neither are easy to fix
               (only because of the number of drivers that would be impacted):

               1. The class drivers only send EP0 write requests and these are
                  only queued on EP0 IN by this drivers.  There is never a read
                  request queued on EP0 OUT.
               2. But EP0 OUT data could be buffered in a buffer in the driver
                  data structure.  However, there is no method currently
                  defined in the USB device interface to obtain the EP0 data.

               Updates:  (1) The USB device-to-class interface as been extended so
               that EP0 OUT data can accompany the SETUP request sent to the
               class drivers. (2) The logic in the STM32 F4 OTG FS device driver
               has been extended to provide this data.  Updates are still needed
               to other drivers.
  Status:      Open
  Priority:    High for class drivers that need EP0 data.  For example, the
               CDC/ACM serial driver might need the line coding data (that
               data is not used currenly, but it might be).

o Libraries (lib/)
  ^^^^^^^^^^^^^^^^

  Title:       ENVIRON
  Description: The definition of environ in stdlib.h is bogus and will not
               work as it should.  This is because the underlying
               representation of the environment is not an arry of pointers.
  Status:      Open
  Priority:    Medium

  Title:       TERMIOS
  Description: Need some minimal termios support... at a minimum, enough to
               switch between raw and "normal" modes to support behavior like
               that needed for readline().
               UPDATE:  There is growing functionality in lib/termios/ and in the
               ioctl methods of several MCU serial drivers (stm32, lpc43, lpc17,
               pic32).  However, as phrased, this bug cannot yet be closed since
               this "growing functionality" does not address all termios.h
               functionality and not all serial drivers support termios.
  Status:      Open
  Priority:    Low

  Title:       DAYS OF THE WEEK
  Description: strftime() and other timing functions do not handle days of the week.
  Status:      Open
  Priority:    Low

  Title:       RESETTING GETOPT()
  Description: There is an issue with the way that getopt() handles errors that
               return '?'.
               
               1. Does getopt() reset its global variables after returning '?' so
                  that it can be re-used?  That would be required to support where
                  the caller terminates parsing before reaching the last parameter.
               2. Or is the client expected to continue parsing after getopt()
                  returns '?'  and parse until the final parameter?
            
               The current getopt() implementation only supports #2.
  Status:      Open
  Priority:    Low

  Title:       FERROR() AND CLEARERR()
  Description: Not implemented: ferror() and clearerr()
  Status:      Open
  Priority:    Low

  Title:       CONCURRENT STREAM READ/WRITE
  Description: NuttX only supports a single file pointer so reads and writes 
               must be from the same position.  This prohibits implementation
               of behavior like that required for fopen() with the "a+" mode.
               According to the fopen man page:
               
               "a+ Open for reading and appending (writing at end of file).
                The file is created if it does not exist. The initial file
                position for reading is at the beginning of the file, but
                output is always appended to the end of the file."

               At present, the single NuttX file pointer is positioned to the
               end of the file for both reading and writing.
  Status:      Open
  Priority:    Medium.  This kind of operation is probably not very common in
               deeply embedded systems but is required by standards.

  Title:       DIVIDE BY ZERO
  Description: This is bug 3468949 on the SourceForge website (submitted by
               Philipp Klaus Krause):
               "lib_strtod.c does contain divisions by zero in lines 70 and 96.
                AFAIK, unlike for Java, division by zero is not a reliable way to
                get infinity in C. AFAIK compilers are allowed e.g. give a compile-
                time error, and some, such as sdcc, do. AFAIK, C implementations
                are not even required to support infinity. In C99 the macro isinf()
                could replace the first use of division by zero. Unfortunately, the
                macro INFINITY from math.h probably can't replce the second division
                by zero, since it will result in a compile-time diagnostic, if the
                implementation does not support infinity."
  Status:       Open
  Priority:     

  Title:       OLD dtoa NEEDS TO BE UPDATED
  Description: This implementation of dtoa in lib/stdio is old and will not
               work with some newer compilers.  See 
               http://patrakov.blogspot.com/2009/03/dont-use-old-dtoac.html
  Status:      Open
  Priority:    ??

  Title:       SYSLOG INTEGRATION
  Description: There are the beginnings of some system logging capabilities (see
               drivers/syslog, fs/fs_syslog.c, and lib/stdio/lib_librawprintf.c and
               lib_liblowprintf.c.  For NuttX, SYSLOG is a concept and includes,
               extends, and replaces the legacy NuttX debug ouput.  Some additional
               integration is required to formalized this.  For example:

               o lib_rawprintf() shjould be renamed syslog().
               o debug.h should be renamed syslog.h
               o And what about lib_lowprintf()? llsyslog?
  Status:      Open
  Priority:    Low -- more of a roadmap

  Title:       FLOATING POINT FORMATS
  Description: Only the %f floating point format is supported.  Others are accepted
               but treated like %f.
  Status:      Open
  Priority:    Medium (this might important to someone).

  Title:       FLOATING POINT PRECISION
  Description: A fieldwidth and precision is required with the %f format.  If %f
               is used with no format, than floating numbers will be printed with
               a precision of 0 (effectively presented as integers).
  Status:      Open
  Priority:    Medium (this might important to someone).

o File system / Generic drivers (fs/, drivers/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  NOTE:  The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt

  Title:       CHMOD() AND TRUNCATE()
  Description: Implement chmod(), truncate().
  Status:      Open
  Priority:    Low

  Title:       CAN POLL SUPPORT
  Description: At present, the CAN driver does not support the poll() method.
               See drivers/can.c
  Status:      Open
  Priority:    Low

  Title:       REMOVING PIPES AND FIFOS
  Description: There is no way to remove a FIFO or PIPE created in the
               pseudo filesystem.  Once created, they persist indefinitely
               and cannot be unlinked.  This is actually a more generic
               issue:  unlink does not work for anything in the pseudo-
               filesystem.
  Status:      Open, but partially resolved: pipe buffer is at least freed
               when there are not open references to the pipe/FIFO.
  Priority:    Medium

  Title:       ROMFS CHECKSUMS
  Description: The ROMFS file system does not verify checksums on either
               volume header on on the individual files.
  Status:      Open
  Priority:    Low.  I have mixed feelings about if NuttX should pay a
               performance penalty for better data integrity.

  Title:       SPI-BASED SD MULTIPLE BLOCK TRANSFERS
  Description: The simple SPI based MMCS/SD driver in fs/mmcsd does not
               yet handle multiple block transfers.
  Status:      Open
  Priority:    Medium-Low

  Title:       READ-AHEAD/WRITE BUFFER UNTESTED
  Description: Block driver read-ahead buffer and write buffer support is
               implemented but not yet tested.
  Status:      Open
  Priority:    Low

  Title:       SDIO-BASED SD READ-AHEAD/WRITE BUFFERING INCOMPLETE
  Description: The drivers/mmcsd/mmcsd_sdio.c driver has hooks in place to
               support read-ahead buffering and write buffering, but the logic
               is incomplete and untested.
  Status:      Open
  Priority:    Low

  Title:       POLLHUP SUPPORT
  Description: All drivers that support the poll method should also report
               POLLHUP event when the driver is closedd.
  Status:      Open
  Priority:    Medium-Low

  Title:       CONFIG_RAMLOG_CONSOLE DOES NOT WORK
  Description: When I enable CONFIG_RAMLOG_CONSOLE, the system does not come up
               propertly (using configuration stm3240g-eval/nsh2).  The problem
               may be an assertion that is occuring before we have a console.
  Status:      Open
  Priority:    Medium

o Graphics subystem (graphics/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  See also the NxWidgets TODO list file for related issues.

  Title:       UNTESTED GRAPHICS APIS
  Description: Testing of all APIs is not complete.  See
               http://nuttx.sourceforge.net/NXGraphicsSubsystem.html#testcoverage
  Status:      Open
  Priority:    Medium

  Title:       ITALIC FONTS / NEGATIVE FONT OFFSETS
  Description: Font metric structure (in include/nuttx/nx/nxfont.h) should allow
               negative X offsets. Negative x-offsets are necessary for certain
               glyphs (and is very common in italic fonts).
               For example Eth, icircumflex, idieresis, and oslash should have
               offset=1 in the 40x49b font (these missing negative offsets are
               NOTE'ed in the font header files).
  Status:      Open.  The problem is that the x-offset is an unsigned bitfield
               in the current structure.
  Priority:    Low.

  Title:       RAW WINDOW AUTORAISE
  Description: Auto-raise only applies to NXTK windows. Shouldn't it also apply
               to raw windows as well?
  Status:      Open
  Priority:    Low

  Title:       AUTO-RAISE DISABLED
  Description: Auto-raise is currently disabled in NX multi-server mode.  The
               reason is complex:
               - Most touchscreen controls send touch data a high rates
               - In multi-server mode, touch events get queued in a message
                  queue.
               - The logic that receives the messages performs the auto-raise.
                 But it can do stupid things after the first auto-raise as
                 it opperates on the stale data in the message queue.
               I am thinking that auto-raise ought to be removed from NuttX
               and moved out into a graphics layer (like NxWM) that knows
               more about the appropriate context to do the autoraise.
  Status:      Open
  Priority:    Medium low

  Title:       IMPROVED NXCONSOLE FONT CACHING
  Description: Now each NxConsole instance has its own private font cache
               whose size is determined by CONFIG_NXCONSOLE_MXCHARS.  If there
               are multiple NxConsole instances using the same font, each will
               have a separate font cache.  This is inefficient and wasteful
               of memory:  Each NxConsole instance should share a common font
               cache.
  Status:      Open
  Priority:    Medium.  Not important for day-to-day testing but would be
               a critical improvement if NxConsole were to be used in a
               product.
 
o Pascal Add-On (pcode/)
  ^^^^^^^^^^^^^^^^^^^^^^

  Title:       P-CODES IN MEMORY UNTESTED
  Description: Need APIs to verify execution of P-Code from memory buffer.
  Status:      Open
  Priority:    Low

  Title:       SMALLER LOADER AND OBJECT FORMAT
  Description: Loader and object format may be too large for some small
               memory systems.  Consider ways to reduce memory footprint.
  Status:      Open
  Priority:    Medium

o Documentation (Documentation/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       DOCUMENT APIS USABLE FROM INTERRUPT HANDLERS
  Description: Need to document which APIs can be used in interrupt
               handlers (like mq_send and sem_post) and which cannot.
  Status:      Open
  Priority:    Low

o Build system
  ^^^^^^^^^^^^

  Title:       NUTTX CONFIGURATION TOOL
  Description: Need a NuttX configuration tool.  The number of configuration
               settings has become quite large and difficult to manage manually.
               Update:  This task is essentially completed.  But probably not for
               all platforms and all features.  When do we know that the the
               features is complete and that we can switch to exclusive use of
               the tool?
  Status:      Open
  Priority:    Medium-low

  Title:       NATIVE WINDOWS BUILD
  Description: At present, NuttX builds only under Linux or Cygwin.
               Investigate the possibility of a native Windows build using
               something like the GNUWin32 tools (coreutils+make+grep+sed+uname).
  Status:      Open
  Priority:    Low

  Title:       WINDOWS DEPENDENCY GENERATION
  Description: Dependency generation is currently disabled when a Windows native
               toolchain is used.  I think that the only issue is that all of the
               Windows dependencies needed to be quoted in the Make.dep files.
  Status:      Open
  Priority:    Low -- unless some dependency-related build issues is discovered.

  Title:       SETENV.H
  Description: Logic in most setenv.sh files can create the following problem
               on many platforms:

                 $ . ./setenv.sh
                 basename: invalid option -- 'b'
                 Try `basename --help' for more information.

               The problem is that $0 is the current running shell which may include
               a dash in front:

                 $ echo $0
                 -bash

               But often is just /bin/bash (and the problem does not occur.  The fix
               is:

                 -if [ "$(basename $0)" = "setenv.sh" ]; then
                 +if [ "$_" = "$0" ] ; then
  Status:      Open
  Priority:    Low.  Use of setenv.sh is optional and most platforms do not have
               this problem.  Scripts will be fixed one-at-a-time as is appropropriate.

  Title:       MAKE EXPORT LIMITATIONS
  Description: The top-level Makefile 'export' target that will bundle up all of the
               NuttX libraries, header files, and the startup object into an export-able
               tarball. This target uses the tools/mkexport.sh script.  Issues:

               1. This script assumes the host archiver ar may not be appropriate for
                  non-GCC toolchains
               2. For the kernel build, the user libraries should be built into some
                  libuser.a.  The list of user libraries would have to accepted with
                  some new argument, perhaps -u.
  Status:      Open
  Priority:    Low.

  Title:       KERNEL BUILD MODE ISSUES - GRAPHICS/NSH PARTITIONING.
  Description: In the kernel build mode (where NuttX is built as a monlithic
               kernel and user code must trap into the protected kernel via
               syscalls), the single user mode cannot be supported.  In this
               built configuration, only the multiple user mode can be supported
               with the NX server residing inside of the kernel space.  In
               this case, most of the user end functions in graphics/nxmu
               must be moved to lib/nx and those functions must be built into
               libuser.a to be linked with the user-space code.
               A similar issue exists in NSH that uses some internal OS
               interfaces that would not be available in a kernel build
               (such as foreach_task, foreach_mountpoint, etc.).
  Status:      Open
  Priority:    Low -- the kernel build configuration is not fully fielded
               yet.

o Linux/Cywgin simulation (arch/sim)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       SIMULATED SERIAL DRIVER
  Description: The simulated serial driver has some odd behavior.  It
               will stall for a long time on reads when the C stdio buffers are
               being refilled. This only effects the behavior of things like
               fgetc().  Workaround: Set CONFIG_STDIO_BUFFER_SIZE=0, suppressing
               all C buffered I/O.
  Status:      Open
  Priority:    Low (because the simulator is only a test/development platform)

  Title:       SIMULATOR NETWORKING SUPPORT
  Description: I never did get networking to work on the sim Linux target.  On Linux,
               it tries to use the tap device (/dev/net/tun) to emulate an Ethernet
               NIC, but I never got it correctly integrated with the NuttX networking.
               NOTE: On Cygwin, the build uses the Cygwin WPCAP library and is, at
               least, partially functional (it has never been rigorously tested).
  Status:      Open
  Priority:    Low (unless you want to test networking features on the simulation).
  
  Title:       ROUND-ROBIN SCHEDULING IN THE SIMULATOR
  Description: Since the simulation is not pre-emptible, you can't use round-robin
               scheduling (no time slicing).  Currently, the timer interrupts are
               "faked" during IDLE loop processing and, as a result, there is no
               task pre-emption because there are no asynchrous events.  This could
               probably be fixed if the "timer interrupt" were driver by Linux
               signals. NOTE:  You would also have to implement irqsave() and
               irqrestore() to block and (conditionally) unblock the signal.
  Status:      Open
  Priority:    Low
  
  Title:       NSH ISSUES ON THE SIMULATOR
  Descripion:  The NSH example has some odd behaviors.  Mult-tasking -- for example,
               execution of commands in background -- does not work normally.  This
               is due to the fact that NSH uses the system standard input for the
               console.  This means that the simulation is actually "frozen" all of
               the time when NSH is waiting for input and background commands never
               get the chance to run.
  Status:      Open
  Priority:    This will not be fixed.  This is the normal behavior in the current
               design of the simulator.  "Real" platforms will behave correctly
               because NSH will "sleep" when it waits for console inpu and other
               tasks can run freely.

  Title:       DOUBLE COMMAND ECHO
  Description: In the NSH example, the host HOST echoes each command so after you
               you enter a command, the command is repeated on the next line.  This
               is an artifact of the simulator only.
  Status:      Open
  Priority:    This will not be fixed.  This is the normal behavior in the current
               design of the simulator.  "Real" platforms will behave correctly.

o ARM (arch/arm/)
  ^^^^^^^^^^^^^^^

  Title:       IMPROVED ARM INTERRUPT HANDLING
  Description: ARM interrupt handling performance could be improved in some
               ways. One easy way is to use a pointer to the context save
               area in current_regs instead of using up_copystate so much.
               see handling of 'current_regs" in arch/arm/src/armv7-m/* for
               examples of how this might be done.
  Status:      Open
  Priority:    Low

  Title:       IMPROVED ARM INTERRUPT HANDLING
  Description: The ARM and Cortex-M3 interrupt handlers restores all regisers
               upon return. This could be improved as well:  If there is no
               context switch, then the static registers need not be restored
               because they will not be modified by the called C code.
               (see arch/sh/src/sh1/sh1_vector.S for example)
  Status:      Open
  Priority:    Low

  Title:       SVCALLS AND HARDFAULTS
  Description: The Cortex-M3 user context switch logic uses SVCall instructions.
               This user context switching time could be improved by eliminating
               the SVCalls and developing assembly language implementations
               of the context save and restore logic.
               Also, because interrupts are always disabled when the SVCall is
               executed, the SVC goes to the hard fault handler where it must
               be handled as a special case.  I recall seeing some controls
               somewhere that will allow to suppress one hard fault.  I don't 
               recall the control, but something like this should be used before
               executing the SVCall so that it vectors directly to the SVC
               handler.
               Another, more standard option would be to use interrupt priority
               levels to control interrupts.  In that case, (1) The SVC would
               be the highest priority interrupt (0), (2) irqsave() would set
               the interrupt mask level to just above that, and (2) irqrestore
               would restore the interrupt level.  This would not be diffult,
               but does affect a lot of files!
  Status:      Open
  Priority:    Low

  Title:       ARM INTERRUPTS AND USER MODE
  Description: The ARM interrupt handling (arch/arm/src/arm/up_vectors.S) returns
               using 'ldmia   sp, {r0-r15}^'  My understanding is that this works
               fine because everything is in kernel-mode.  In an operating model
               where applications run in user mode and interrupts/traps run in
               kernel-mode, I think that there is a problem with this.  This would
               like be a problem, for example, if for a kernel build where NuttX
               is built as a monolithic, protected kernel and user mode programs
               trap into the kernel.
  Status:      Open
  Priority:    Low until I get around to implementng security or kernel mode for
               the ARM platform.

  Title:       CORTEX-M3 STACK OVERFLOW
  Description: There is bit bit logic inf up_fullcontextrestore() that executes on
               return from interrupts (and other context switches) that looks like:

                 ldr r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */
                 msr cpsr, r1 /* Set the CPSR */

                 /* Now recover r0 and r1 */

                 ldr r0, [sp]
                 ldr r1, [sp, #4]
                 add sp, sp, #(2*4)

                 /* Then return to the address at the stop of the stack,
                  * destroying the stack frame
                  */

                 ldr pc, [sp], #4

               Under conditions of excessivley high interrupt conditions, many
               nested interrupts can oocur just after the 'msr cpsr' instruction.
               At that time, there are 4 bytes on the stack and, with each
               interrupt, the stack pointer may increment and possibly overflow.

               This can happen only under conditions of continuous interrupts.
               See this email thread: http://tech.groups.yahoo.com/group/nuttx/message/1261
               On suggested change is:

                 ldr  r1, [r0, #(4*REG_CPSR)] /* Fetch the stored CPSR value */
                 msr spsr_cxsf, r1 /* Set the CPSR */
                 ldmia     r0, {r0-r15}^

               But this has not been proven to be a solution.
  Status:      Open
  Priority:    Low.  The conditions of continous interrupts is really the problem.
               If your design needs continous interrupts like this, please try
               the above change and, please, submit a patch with the working fix.

  Title:       KERNEL MODE ISSUES - HANDLERS
  Description: The is a design flaw in the ARM/Cortex trap handlers.  Currently,
               they try to process the SYSCALL within the trap handler.  That
               cannot work.  There are two possibilities to fix this.
               1) Just enable interrupts in the trap handler and make sure that
                  that sufficient protection is in place to handler the nested
                  interrupts, or
               3) Return from the exception via a trampoline (such as is
                  currently done for signal handlers).  In the trampoline,
                  the trap would processed in supervisor mode with interrupts
                  enabled.
  Status:      Open
  Priority:    medium-high.

o ARM/C5471 (arch/arm/src/c5471/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       UART RECONFIGURATION
  Description: UART re-configuration is untested and conditionally compiled out.
  Status:      Open
  Priority:    Medium.  ttyS1 is not configured, but not used; ttyS0 is configured
               by the bootloader

o ARM/DM320 (arch/arm/src/dm320/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       DEBUG ISSUES
  Description: config/ntos-dm320: It seems that when a lot of debug statements
               are added, the system no longer boots.  This is suspected to be
               a stack problem: Making the stack bigger or removing arrays on
               the stack seems to fix the problem (might also be the
               bootloader overwriting memory)
  Status:      Open
  Priority:    Medium

  Title:       USB DEVICE DRIVER UNTESTED
  Description: A USB device controller driver was added but has never been tested.
  Status:      Open
  Priority:    Medium

  Title:       FRAMEBUFFER DRIVER UNTESTED
  Description: A framebuffer "driver" was added, however, it remains untested.
  Status:      Open
  Priority:    Medium

  Title:       VIDEO ENCODER DRIVER
  Description: In order to use the framebuffer "driver" additional video encoder
               logic is required to setupt composite video output or to interface
               with an LCD.
  Status:      Open
  Priority:    Medium (high if you need to use the framebuffer driver)

o ARM/i.MX (arch/arm/src/imx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       PORT IS INCOMPLETE
  Description: The basic port of the i.MX1 architecuture was never finished.  The port
               is incomplete (as of this writing, is still lacks a timer, interrupt
               decoding, USB, network) and untested.
  Status:      Open
  Priority:    Medium (high if you need i.MX1/L support)

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

o ARM/LPC17xx (arch/arm/src/lpc17xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       USB DMA INCOMPLETE
  Description: USB DMA not fully implemented. Partial logic is in place but it is
               fragmentary and bogus. (Leveraged from the lpc214x)
  Status:      Open
  Priority:    Low

  Title:       SSP DRIVER IMPROVEMENTS
  Description: a) At present the SSP driver is polled.  Should it be interrupt driven?
                  Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
                  interrupt driven SPI driver.  Should be very easy to part that architecture
                  to the LPC.
               b) See other SSP (SPI) driver issues listed under ARM/LPC214x.  The LPC17xx
                  driver is a port of the LPC214x driver and probably has the same issues.
               b) Other SSP driver improvements: Add support for multiple devices on the
                  SSP bus, use DMA data transfers
  Status:      Open
  Priority:    Medium

  Title:       NOKIA LCD DRIVER NONFUNCTIONAL
  Description: An LCD driver for the Olimex LPC1766STK has been developed.  However, that
               driver is not yet functional on the board:  The backlight comes on, but
               nothing is visible on the display.
  Status:      Open
  Priority:    Medium-Low (unless you need the display on the LPC1766STK!)

o ARM/LPC214x (arch/arm/src/lpc214x/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       VECTOR INTERRUPTS
  Description: Should use Vector Interrupts
  Status:      Open
  Priority:    Low

  Title:       USB DMA INCOMPLETE
  Description: USB DMA not fully implemented. Partial logic is in place but it is
               fragmentary and bogus.
  Status:      Open
  Priority:    Low

  Title:       USB SERIAL DRIVER REPORTS WRONG ERROR
  Description: USB Serial Driver reports wrong error when opened before the
               USB is connected (reports EBADF instead of ENOTCONN)
  Status:      Open
  Priority:    Low

  Title:       SPI DRIVER IMPROVEMENTS
  Description: At present the SPI driver is polled.  Should it be interrupt driven?
               Look at arch/arm/src/imx/imx_spi.c -- that is a good example of an
               interrupt driven SPI driver.  Should be very easy to part that architecture
               to the LPC.
  Status:      Open
  Priority:    Medium

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

  Title:       SPI DRIVER DELAYS
  Description: At present the SPI driver is polled -AND- there is a rather large, arbitrary,
               delay in one of the block access routines.  The purpose of the delay is to
               avoid a race conditions.  This begs for a re-design -OR- at a minimum, some
               optimiation of the delay time.
  Status:      Open
  Priority:    Medium

  Title:       2GB SD CARD ISSUES
  Desription:  I am unable to initialize a 2Gb SanDisk microSD card (in adaptor) on the
               the mcu123 board.  The card fails to accept CMD0.  Doesn't seem like a software
               issue, but if anyone else sees the problem, I'd like to know.
               Related:  Fixes were recently made for the SDIO-based MMC/SD driver to
               support 2Gb cards -- the blocksize was forced to 512 in all cases.  The SPI-
               based driver may also have this problem (but I don't think this would have
               anything to do with CMD0).
  Status:      Open
  Priority:    Uncertain

  Title:       USB BROKEN?
  Description: I tried to bring up the new configuration at configs/mcu123-214x/composite,
               and Linux failed to enumerate the device.  I don't know if this is 
               a problem with the lpc214x USB driver (bit rot), or due to recent
               changed (e.g., -r4359 is suspicious), or an incompatibility between the
               Composite driver and the LPC214x USB driver.  It will take more work
               to find out which -- like checking if the other USB configurations are
               also broken.
  Status:      Open
  Priority:    It would be high if the LPC2148 were a current, main stream architecture.
               I am not aware of anyone using LPC2148 now so I think the priority has
               to be low.

o ARM/LPC31xx (arch/arm/src/lpc31xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       PLATFORM-SPECIFIC LOGIC
  Description: arch/arm/src/lpc313x/lpc313x_spi.c contains logic that is specific to the
               Embedded Artist's ea3131 board.  We need to abstract the assignment of SPI
               chip selects and logic SPI functions (like SPIDEV_FLASH).  My thoughts are:
               - Remove lpc313x_spiselect and lpc313x_spistatus from lpc313x_internal.h
               - Remove configs/ea3131/src/up_spi.c
               - Add configurations CONFIG_LPC3131x_CSOUT1DEV, CONFIG_LPC3131x_CSOUT2DEV,
                 and CONFIG_LPC3131x_CSOUT3DEV that maps the lpc313x SPI chip selects to
                 SPIDEV_* values.
               - Change arch/arm/src/lpc313x/lpc313x_spi.c to use those configuration
                 settings.
  Status:      Open
  Priority:    High if you want to use SPI on any board other than the ea3131.

  Title:       SPI DRIVER
  Description: arch/arm/src/lpc313x/lpc313x_spi.c may or may not be functional.  It was
               reported to be working, but I was unable to get it working with the
               Atmel at45dbxx serial FLASH driver.
  Status:      Open
  Priority:    High if you need to use SPI.

o ARM/LPC43x (arch/arm/src/lpc43xx/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

o ARM/STR71x (arch/arm/src/str71x/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       UNVERIFIED MMC SUPPORT
  Description: Verify SPI driver and integrate with MMC support. This effort is stalled
               at the moment because the slot on the Olimex board only accepts MMC card;
               I have no MMC cards, only SD cards which won't fit into the slot.
  Status:      Open
  Priority:    Medium

  Title:       NO USB DRIVER
  Description: Develop a USB driver and integrate with existing USB serial and storage
               class drivers.
  Status:      Open
  Priority:    Medium

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

o ARM/LM3S6918 (arch/arm/src/lm3s/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       I2C DRIVER
  Description: Still need to implement I2C
  Status:      Open
  Priority:    Low

  Title:       SSI OVERRUNS
  Description: Should terminate SSI/SPI transfer if an Rx FIFO overrun occurs.
               Right now, if an Rx FIFO overrun occurs, the SSI driver hangs.
  Status:      Open
  Priority:    Medium, If the transfer is properly tuned, then there should not
               be any Rx FIFO overruns.

  Title:       THTTPD BUGS
  Description: There are some lingering bugs in THTTPD, possibly race conditions.  This
               is covered above under Network Utilities, but is duplicated here
               to point out that the LM3S suffers from this bug.
  Status:      Open.
               UPDATE: I have found that increasing the size of the CGI program stack
               from 1024 to 2048 (on the LM3S) eliminates the problem.  So the most
               likely cause is probably a stack overflow, not a hard sofware bug.
  Priority:    Probably Low

o ARM/STM32 (arch/arm/src/stm32/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       NOR FLASH DRIVER
  Description: NOR Flash driver with FTL layer to support a file system.
  Status:      Open
  Priority:    Low

  Title:       USBSERIAL ISSUES
  Description  A USB device-side driver is in place but not well tested.  At
               present, the apps/examples/usbserial test sometimes fails.  The situation
               that causes the failure is:

               - Host-side of the test started after the target side sends the
                 first serial message.

               The general failure is as follows:

               - The target message pends in the endpoint packet memory
               - When the host-side of the test is stated, it correctly
                 reads this pending data.
               - an EP correct transfer interrupt occurs and the next
                 pending outgoing message is setup
               - But, the host never receives the next message

               If the host-side driver is started before the first target message
               is sent, the driver works fine.
  Status:      Open
  Priority:    Medium-High
  
  Title:       FSMC EXTERNAL MEMORY UNTESTED
  Description: FSMC external memory support is untested
  Status:      Open
  Priority:    Low

  Title:       DMA EXTENSIONS
  Description: DMA logic needs to be extended.  DMA2, Channel 5, will not work
               because the DMA2 channels 4 & 5 share the same interrupt.
  Status:      Open
  Priority:    Low until someone needs DMA1, Channel 5 (ADC3, UART4_TX, TIM5_CH1, or
               TIM8_CH2).

  Title:       UNFINISHED DRIVERS
  Description: The following drivers are incomplete:  DAC.  The following drivers
               are untested:  DMA on the F4, CAN.
  Status:      Open
  Priority:    Medium

  Title:       F4 SDIO MULTI-BLOCK TRANSFER FAILURES
  Description: If you use a large I/O buffer to access the file system, then the
               MMCSD driver will perform multiple block SD transfers.  With DMA
               ON, this seems to result in CRC errors detected by the hardware
               during the transfer.  Workaround:  CONFIG_MMCSD_MULTIBLOCK_DISABLE=y.
  Status:      Open
  Priority:    Medium

  Title:       DMA BOUNDARY CROSSING
  Description: I see this statement in the reference manual:  "The burst
               configuration has to be selected in order to respect the AHB protocol,
               where bursts must not cross the 1 KB address boundary because the
               minimum address space that can be allocated to a single slave
               is 1 KB. This means that the 1 KB address boundary should not be crossed
               by a burst block transfer, otherwise an AHB error would be generated,
               that is not reported by the DMA registers."

               The implication is that there may be some unenforced alignment
               requirements for some DMAs.  There is nothing in the DMA driver to
               prevent this now.
  Status:      Open
  Priority:    Low (I am not even sure if this is a problem yet).

  Status:      UNFINISHED STM32 F4 OTG FS HOST DRIVER
  Description: A quick-n-dirty leverage of the the LPC17xx host driver was put into
               the STM32 source to support development of the STM32 F4 OTG FS host
               driver.  It is non-functional and still waiting for STM32 F4 logic
               to be added.  Don't use it!
  Status:      Open
  Priority:    Low (unless you need a host driver).

o AVR (arch/avr)
  ^^^^^^^^^^^^^^

  Title:        AMBER WEB SERVER UNTESTED
  Description:  There is a port for the Amber Web Server ATMega128, however this is
                completely untested due to the lack to compatible, functional test
                equipment.
  Status:       Open
  Priority:     The priority might as well be low since there is nothing I can do about
                it anyway.

  Title:        STRINGS IN RAM
  Description:  Many printf-intensive examples (such as the OS test) cannot be executed
                on most AVR platforms.  The reason is because these tests/examples
                generate a lot of string data.  The build system currently places all
                string data in RAM and the string data can easily overflow the tiny
                SRAMs on these parts.  A solution would be to put the string data
                into the more abundant FLASH memory, but this would require modification
                to the printf logic to access the strings from program memory.
  Status:       Open
  Priority:     Low.  The AVR is probably not the architecuture that you want to use
                for extensive string operations.

  Title:        SPI AND USB DRIVERS UNTESTED
  Description:  An SPI driver and a USB device driver exist for the AT90USB (as well
                as a USB mass storage example).  However, this configuration is not
                fully debugged as of the NuttX-6.5 release.
                Update 7/11:  (1) The SPI/SD driver has been verified, however, (2) I
                believe that the current teensy/usbstorage configuration uses too
                much SRAM for the system to behave sanely.  A lower memory footprint
                version of the mass storage driver will be required before this can
                be debugged
  Status:       Open
  Priority:     Medium-High.

  Title:        AVR32 PORT IS NOT FULLY TESTED
  Description:  A complete port for the AVR32 is provided and has been partially
                debugged.  There may still be some issues with the serial port
                driver.
  Status:       Open
  Priority:     Medium

o Intel x86 (arch/x86)
  ^^^^^^^^^^^^^^^^^^^^

o 8051 / MCS51 (arch/8051/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       STACK OVERFLOWS DURING INTERRUPT HANDLING
  Description: Current status:
               - Basic OS task management seems OK
               - Fails when interrupts enabled.  The stack pointer is around
                 0x6e before the failure occurs.  It looks like some issue
                 when the stack pointer moves from the directly to indirectly
                 addressable region (0x80 boundary).
               - Work on the 8052 is temporarily on hold
  Status:      Open
  Priority:    Low, 8051 is a tough platform because of the tiny stack.

  Title:       TIMER 0 AS SYSTEM TIMER
  Description: Use timer 0 as system timer.  Timer 2 is needed for second UART.
               Logic is implemented, but there needs to be a system
               configuration to change the ticks-per-second value to match the
               timer interrupt rate
  Status:      Open
  Priority:    Low

  Title:       OVERFLOWS DURING BUILD
  Description: During build, there are several integer overflows reported:
               sched/gmtime_r.c aroud lines 184 and 185
               sched/clock_initialize.c at line 107
               sched/pthread_create.c at 330
               apps/examples/ostest/barrier.c around lines 53 and 74
               apps/examples/ostest/sighand.c at 225 and 244
               driver/serial.c in usleep calls around 347 and 354
  Status:      Open.  Update:  These were reviewed during the hcs12 port.  The
               hcs12 also has 16-bit integer types (if -mshort is in the CFLAGS).
               I believe that the warnings in most of the above have been fixed
               but this has not been verified on this platform).
  Priority:    Medium

  Title:       DATA INITIALIZATION
  Description  Global data is not being initialized.  Logic like that of SDCCs
               crt0*.s needs to be incorporated into the system boot logic
  Status:      Open
  Priority:    Low -- only because there as so many other issues with 8051

o MIPS/PIC32(arch/mips)
  ^^^^^^^^^^^^^^^^^^^^^

  Title:       PIC32 USB DRIVER DOES NOT WORK WITH MASS STORAGE CLASS
               UPDATE:  ** ONLY USING RAM DISK FOR EXPORTED VOLUME ***
  Description: The PIC32 USB driver either crashes or hangs when used with
               the mass storage class when trying to write files to the target
               storage device.  This usually works with debug on, but does not
               work with debug OFF (implying some race condition?)

               Here are some details of what I see in debugging:

               1. The USB MSC device completes processing of a read request
                  and returns the read request to the driver.
               2. Before the MSC device can even begin the wait for the next
                  driver, many packets come in at interrupt level.  The MSC
                  device goes to sleep (on pthread_cond_wait) with all of the
                  read buffers ready (16 in my test case).
               3. The pthread_cond_wait() does not wake up.  This implies
                  a problem with pthread_con_wait(?).  But in other cases,
                  the MSC device does wake up, but then immediately crashes
                  because its stack is bad.
               4. If I force the pthread_cond_wait to wake up (by using
                  pthread_cond_timedwait instead), then the thread wakes
                  up and crashes with a bad stack.

               So far, I have no clue why this is failing.

               UPDATE:  This bug was recorded using the PIC32 Ethernet
               Starter kit with a RAM disk (that board has no SD card slot).
               Howevever, using the USB mass storage device with the
               Mikroelektronika using a real SD card, there is no such
               problem -- the mass storage device seems quite stable.

               UPDATE:  Hmmm.. retesting with the Mikroelectronka board
               shows problems again.  I think that there are some subtle
               timing bugs whose effects can very from innocuous to severe.
  Status:      Open
  Priority:    Originally, High BUT reduced to very Low based on the
               UPDATED comments.

  Title:       PIC32 USB MASS STORAGE DEVICE FAILS TO RE-CONNECT
  Description: Found using configuration configs/pic32mx7mmb/nsh.
               In this configuratin, the NSH 'msconn' command will connect the
               mass storage device to the host; the 'msdis' command will
               disconnect the device.  The first 'msconn' works perfectly.
               However, when attempting to re-connect, the second 'msconn'
               command does not command properly:  Windows reports an
               unrecognized device.  Apparently, some state is being properly
               reset when the mass storage device is disconnected.  Shouldn't
               be hard to fix.
  Status:      Open
  Priority:    Medium

  Title:       POSSIBLE INTERRUPT CONTROL ISSUE
  Description: There is a kludge in the file arch/mips/src/common/up_idle.c.
               Basically, if there is nothing else going on in the IDLE loop,
               you have to disable then re-enable interrupts.  Logically nothing
               changes, but if you don't do this interrupts will be be disabled
               in the IDLE loop which is a very bad thing to happen.

               Some odd behavior in the interrupt setup on the IDLE loop is
               not really a big concern, but what I do not understand is if
               this behavior is occurring on all threads after all context
               switches:  Are interrupts always disabled until re-enabled?
               This requires some further investigation at some point; it
               may be nothing but may also be a symptom of some changes
               required to the interrupt return logic (perhaps some CP0
               status hazard?)
  Status:      Open
  Priority:    Low. Puzzling and needs some investigation, but there there
               is no known misbehavior.

o Hitachi/Renesas SH-1 (arch/sh/src/sh1)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:        SH-1 IS UNUSABLE
  Description:  There are instabilities that make the SH-1 port un-usable.  The
                nature of these is not understood; the behavior is that certain SH-1
                instructions stop working as advertised.  I have seen the following
                examples:

                  412b jmp @r1 - Set a return address in PR, i.e., it behaved like
                       410b jsr @r1.  Normally 412b works correctly, but in the failure
                       condition, it reliably set the PR.
                  69F6 mov.l @r15+,r9 - wrote the value of R1 to @r15+.  This behavior
                       does not correspond to any known SH-1 instruction

                This could be a silicon problem, some pipeline issue that is not
                handled properly by the gcc 3.4.5 toolchain (which has very limit
                SH-1 support to begin with), or perhaps with the CMON debugger.  At
                any rate, I have exhausted all of the energy that I am willing to put
                into this cool old processor for the time being.

                Update:  This bug will probably never be addressed now.  I just
                cleaned house and my old SH-1 was one of the things that went.

  Status:       Open
  Priority:     Low -- because the SH-1, SH7032, is very old and only of historical
                interest.

o Renesas M16C/26 (arch/sh/src/m16c)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:        M16C DOES NOT BUILD
  Description:  The M16C target cannot be built.  The GNU m16c-elf-ld link fails with 
                the following message:

                m32c-elf-ld: BFD (GNU Binutils) 2.19 assertion fail /home/Owner/projects/nuttx/buildroot/toolchain_build_m32c/binutils-2.19/bfd/elf32-m32c.c:482

                Where the reference line is:

                /* If the symbol is out of range for a 16-bit address,
                   we must have allocated a plt entry.  */
                BFD_ASSERT (*plt_offset != (bfd_vma) -1);

                No workaround is known at this time.
  Status:       Open
  Priority:     High -- this is a show stopper for M16C.

  Title:       M16C PORT UNTESTED
  Description: Coding of the initial port is complete, but is untested.
  Status:      Open
  Priority:    Low

  Title:       NO SERIAL CONNECTOR
  Description: Serial drivers were developed for the M16C, however, the SKP16C26
               StarterKit has no serial connectors.
  Status:      Open
  Priority:    Low

  Title:       UNIMPLEMENTED M16C DRIVERS
  Description: Should implement SPI, I2C, Virual EEPROM, FLASH, RTC drivers
  Status:      Open
  Priority:    Medium

o z80/z8/ez80 (arch/z80)
 ^^^^^^^^^^^^^^^^^^^^^^^

  Title:       SDCC INTEGER OVERFLOWS
  Description: The SDCC version the same problems with integer overflow during
               compilation as described for pjrc-8051.  At typical cause is code like
               usleep(500*1000) which exceeds the range of a 16-bit integer.
  Status:      See pjrc-8051.  These have probably been fixed but have not yet
               been verified on these platforms.
  Priority:    See pjrc-8051

  Title:       Z80 SIMULATED CONSOLE
  Description: The simulated Z80 serial console (configs/z80sim/src/z80_serial.c +
               driver/serial.c) does not work.  This is because there are
               no interrupts in the simulation so there is never any serial
               traffic.
  Status:      Open
  Priority:    Low -- the simulated console is not critical path and the designs
               to solve the problem are complex.

  Title:       ZDS-II LIBRARIAN WARNINGS
  Description: ZDS-II Librarian complains that the source for the .obj file
               is not in the library.
  Status:      Open
  Priority:    Low, thought to be cosmetic.  I think this is a consequence of
               replacing vs. inserting the library.

  Title:       ZDS-II COMPILER PROBLEMS
  Description: The ZDS-II compiler (version 4.10.1) fails with an internal error
               while compiler mm/mm_initialize.  This has been reported as
               incident 81509.

               I have found the following workaround that I use to build for the
               time being:

               --- mm/mm_initialize.c.SAVE    2008-02-13 08:06:46.833857700 -0600
               +++ mm/mm_initialize.c    2008-02-13 08:07:26.367608900 -0600
               @@ -94,8 +94,11 @@
               {
                  int i;

               +#if 0 /* DO NOT CHECK IN */
                  CHECK_ALLOCNODE_SIZE;
                  CHECK_FREENODE_SIZE;
               +#endif

               /* Set up global variables */

  Status:      Open
  Priority:    High

  Title:       EZ8 PRIORITY INTERRUPTS
  Description: Add support for prioritized ez8 interrupts.  Currently logic supports
               only nominal interrupt priority.
  Status:      Open
  Priority:    Low

  Title:       Z8ENCORE ONLY VERIFIED ON SIMULATOR
  Description: The z8Encore! port has only been verified on the ZDS-II instruction
               set simulator.
  Status:      Open
  Priority:    Medium

  Title:       XTRS CLEAN
  Description: The XTRS target (configs/xtrs) has a clean problem. The clean
               rule removes .asm files.  This works because there are no .asm
               files except in sub-directories that are provided from 'make clean' --
               except for XTRS:  It has a .asm file in its src/ directory that
               gets removed everytime clean is performd.
  Status:      Open
  Priority:    High if you happen to be working with XTRS.

  Title:       SPI/I2C UNTESTED
  Description: A "generic" SPI and I2C drivers have been coded for the eZ80Acclaim!
               However, these remains untested since I have no SPI or I2C devices for
               the board (yet).
  Status:      Open
  Priority:    Med

  Title:       SPI METHODS ARE NOT THREAD SAFE
  Description: SPI methods are not thread safe.  Needs a semaphore to protect from re-entrancy.
  Status:      Open
  Priority:    Medium -- Will be very high if you do SPI access from multiple threads.

  Title:       I2C UNTESTED
  Description: A "generic" I2C driver has been coded for the eZ8Encore!
               However, this remains untested since I have no I2C devices for
               the board (yet).
  Status:      Open
  Priority:    Med

o z16 (arch/z16)
^^^^^^^^^^^^^^^^

  Title:       ZDS-II LIBRARIAN WARNINGS
  Description: ZDS-II Librarian complains that the source for the .obj file
               is not in the library.
  Status:      Open
  Priority:    Low, thought to be cosmetic.  I think this is a consequence of
               replacing vs. inserting the library.

  Title:       SERIAL DRIVER HANGS
  Description: When the interrupt-driven serial driver is used, the system
               hangs.  This is because of TX ready (TRDE) interrupts that
               get lost while interrupts are disabled.  The existing
               serial driver appears to be limited to hardware with a
               latching, level-sensitive TX ready interrupt.
  Status:      Open
  Priority:    Medium. A polled, write-only serial driver is used in the
               interim for system testing.

  Title:       SYSTEM DELAYS
  Description: The system delays do not appear to be correct with the
               apps/examples/ostest/timedmqueue.c test.
  Status:      Open
  Priority:    Medium-High

  Title:       PROBLEMS WHEN DEBUG DISABLED
  Description: At present, the z16f port does not run properly when CONFIG_DEBUG
               is disabled:  The obvious symptom is that there is no printf()
               output.  I have isolated with problem to errors in optimization.
               With -reduceopt on the command line, I can get the printf output.
               However, there are still errors in the compiled code -- specifically
               in sched/timer_create.c.

               I have submitted a bug report to ZiLOG for this (support incident
               81400).  You can see the status of the bug report (and lots more
               technical detail) here:
               http://support.zilog.com/support/incident/incident_support.asp?iIncidentId=81400&iSiteId=1&chLanguageCode=ENG

               Summary of ZiLOG analysis: "This is a ZNEO compiler problem. ... [a] workaround
               is to replace:
                   if ( !timerid || (clockid != 0) )
                By:
                   if ((clockid != 0) || !timerid)"

  Status:      Open
  Priority:    Medium-High

  Title:       PASCAL ADD-ON
  Description: The pascal add-on does not work with the z16f (that is
               configuration z16f2800100zcog/pashello).  This appears to be
               another ZDS-II error:  when executing the instruction
               SYSIO 0, WRITESTR a large case statement is executed.  This
               involves a call into the ZiLOG runtime library to __uwcase().
               __uwcase is passed a pointer to a structure containing jump
               information.  The cause of the failure appears to be that
               the referenced switch data is bad.
               This is submited as ZiLOG support incident 81459.

               Summary of ZiLOG analysis: "This is a ZNEO run time library problem.
               One workaround is to replace the line 58 in uwcase.asm

               From:
                      ADD       R9,#4             ; Skip handler
               To:
                      ADD       R9,#2             ; Skip handler

               And add uwcase.asm to the project.

               If the customer does not want to modify uwcase.asm then the other
               workaround is to add a dummy case and make it same as default:

               case 0x8000:
               default:

               This will make sure that uwcase is not called but ulcase is called."
  Status:      Open.  Due to licensing issues, I cannot include the modified
               uwcase in the NuttX code base.
  Priority:    Medium

  Title:       USE SPOV
  Description: Add support to maintain SPOV in context switching.  This
               improvement will provide protection against stack overflow
               and make a safer system solution.
  Status:      Open
  Priority:    Low

  Title:       PRIORITIZED INTERRUPTS
  Description: Add support for prioritized interrupts.  Currently logic supports
               only nominal interrupt priority.
  Status:      Open
  Priority:    Low

  Title:       ZDS-II COMPILER PROBLEMS
  Description: The file drivers/mmcsd/mmcsd_sdio.c generates an internal compiler
               error like:
 
               mmcsd\mmcsd_sdio.c
               Internal Error(0503) On line 2504 of "MMCSD\MMCSD_SDIO.C"
                   File <c3>, Args(562,46)

  Status:     Open.  Recommended workaround: remove mmcsd_sdio.c from
              drivers/mmcsd/Make.defs.  There is no SDIO support for the Z16 anyway
  Priority:   Low

o mc68hc1x (arch/hc)
  ^^^^^^^^^^^^^^^^^^

  Title:       BANKED MODE
  Description: There is no script for building in banked mode (more correctly, there
               is a script, but logic inside the script has not yet been implemented).
               It would be necessary to implement banked mode to able to access more
               the 48K of FLASH.
  Status:      Open.
  Priority:    Medium/Low

o Network Utilities (apps/netutils/)

  Title:       UIP RESOLVER
  Description: One critical part of netutils/ apps is untested: The uIP
               resolver in netutils/resolv.  The webclient code has been
               tested on host using gethosbyname(), but still depends on the
               untested resolve logic.
  Status:      Open
  Priority:    Medium, Important but not core NuttX functionality

  Title:       PPP PORT
  Description: Port PPP support from http://contiki.cvs.sourceforge.net/contiki/contiki-2.x/backyard/core/net/ppp/
  Status:      Open
  Priority:    Low

  Title:       UNVERIFIED THTTPD FEATURES
  Description: Not all THTTPD features/options have been verified.  In particular, there is no
               test case of a CGI program receiving POST input.  Only the configuration of
               apps/examples/thttpd has been tested.
  Status:      Open
  Priority:    Medium

  Title:       THE ARP ISSUES AGAIN
  Description: The first GET received by THTTPD is not responded to.  Refreshing the page
               from the browser solves the problem and THTTPD works fine after thatg.  I 
               believe that this is the duplicate of another bug: "Outgoing [uIP] packets are dropped
               and overwritten by ARP packets if the destination IP has not been mapped to a MAC."
  Status:      Open
  Priority:    Medium

  Title:       THTTPD WARNINGS
  Description: If the network is enabled, but THTTPD is not configured, it spews out lots
               of pointless warnings.  This is kind of annoying and unprofessional; needs to
               be fixed someday.
  Status:      Open.  An annoyance, but not a real problem.
  Priority:    Low

o NuttShell (NSH) (apps/nshlib)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       WGET UNTESTED
  Description: The wget command has been incorporated into NSH, however
               it is still untested as of this writing (only because I
               have not had the correct network setup for the testing
               yet).  Since wget depends on the also untest uIP resolv/
               logic, it is like non-functional.
  Status:      Open
  Priority:    Med-High

  Title:       IFCONFIG AND MULTIPLE NETWORK INTERFACES
  Descripton:  The ifconfig command will not behave correctly if an interface
               is provided and there are multiple interfaces.  It should only
               show status for the single interface on the command line; it will
               still show status for all interfaces.
  Status:      Open
  Priority:    Low (multiple network interfaces not fully supported yet anyway).

  Title:       RUN NXFLAT PROGRAMS
  Description: Add support to NSH to run NXFLAT programs from a ROMFS file system
  Status:      Open
  Priority:    Low (enhancement)

  Title:       ARP COMMAND
  Description: Add an ARP command so that we can see the contents of the ARP table.
  Status:      Open
  Priority:    Low (enhancement)

o System libraries apps/system (apps/system)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       READLINE IMPLEMENTATION
  Description: readline implementation does not use C-buffered I/O, but rather
               talks to serial driver directly via read().  It includes VT-100
               specific editting commands.  A more generic readline() should be
               implemented using termios' tcsetattr() to put the serial driver
               into a "raw" mode.
  Status:      Open
  Priority:    Low (unless you are using mixed C-buffered I/O with readline and
               fgetc, for example).

o Other Applications & Tests (apps/examples/)
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

  Title:       EXAMPLES/PIPE ON CYGWIN
  Description: The redirection test (part of examples/pipe) terminates
               incorrectly on the Cywgin-based simulation platform (but works
               fine on the Linux-based simulation platform).
  Status:      Open
  Priority:    Low

  Title:       EXAMPLES/WGET UNTESTED
  Description: examples/wget is untested on the target (it has been tested
               on the host, but not in the target using the uIP resolv logic).
  Status:      Open
  Priority:    Med

  Title:       EXAMPLES/SENDMAIL UNTESTED
  Description: examples/sendmail is untested on the target (it has been tested
               on the host, but not on the target).
  Status:      Open
  Priority:    Med

  Title:       EXAMPLES/NX FONT CACHING
  Description: The font caching logic in examples/nx is incomplete.  Fonts are
               added to the cache, but never removed.  When the cache is full
               it stops rendering.  This is not a problem for the examples/nx
               code because it uses so few fonts, but if the logic were
               leveraged for more general purposes, it would be a problem.
               Update: see examples/nxtext for some improved font cache handling.
  Status:      Open
  Priority:    Low.  This is not really a problem becauses examples/nx works
               fine with its bogus font caching.

  Title:       EXAMPLES/NXTEXT ARTIFACTS
  Description: examples/nxtext.  Artifacts when the pop-up window is opened.
               There are some artifacts that appear in the upper left hand
               corner.  These seems to be related to window creation.  At
               tiny artifact would not be surprising (the initial window
               should like at (0,0) and be of size (1,1)), but sometimes
               the artifact is larger.
  Status:      Open
  Priority:    Medium.