Newer
Older
NuttX TODO List (Last updated January 11, 2013)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
standards, things that could be improved, and ideas for enhancements.
(10) Task/Scheduler (sched/)
(1) Memory Managment (mm/)
patacongo
committed
(2) pthreads (sched/)
(6) Binary loaders (binfmt/)
(17) Network (net/, drivers/net)
(4) USB (drivers/usbdev, drivers/usbhost)
(12) Libraries (libc/, )
(10) File system/Generic drivers (fs/, drivers/)
(5) Graphics subystem (graphics/)
(5) Linux/Cywgin simulation (arch/sim)
patacongo
committed
(6) ARM (arch/arm/)
(2) ARM/i.MX (arch/arm/src/imx/)
(7) ARM/LPC214x (arch/arm/src/lpc214x/)
(0) ARM/LPC43x (arch/arm/src/lpc43xx/)
patacongo
committed
(3) ARM/LM3S6918 (arch/arm/src/lm/)
(5) ARM/STM32 (arch/arm/src/stm32/)
(5) 8051 / MCS51 (arch/8051/)
(1) Hitachi/Renesas SH-1 (arch/sh/src/sh1)
(9) z16 (arch/z16/)
apps/
(5) Network Utilities (apps/netutils/)
(1) System libraries apps/system (apps/system)
(5) Other Applications & Tests (apps/examples/)
Title: CHILD PTHREAD TERMINATION
Description: When a tasks exits, shouldn't all of its child pthreads also be
terminated?
Status: Closed. No, this behavior will not be implemented.
Priority: Medium, required for good emulation of process/pthread model.
Update: These are being fixed as they are encountered. There is
no accounting of how many interfaces have this problem.
Status: Open? There has been an effort over the past few years to assure
that all errno settings are in place. What is the current state?
Unknown.
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.
The primary advantage of a tickless OS is that is would allow for
reduce power consumptions. That is because timer interrupts will
usually awaken CPUs from reduced power consumption states.
Status: Open. There will probably be no tickless OS implementation unless
someone gets motivated and drives the change.
Title: posix_spawn()
Description: This would be a good interface to add to NuttX. It is really
just a re-packaging of the existing, non-standard NuttX exec()
function.
Status: Open. There are no plans to implement this capabilitiey now.
Title: pause() NON-COMPLIANCE
Description: In the POSIX description of this function is the pause() function
will suspend the calling thread until delivery of a signal whose
action is either to execute a signal-catching function or to
terminate the process. The current implementation only waits for
any non-blocked signal to be received. It should only wake up if
the signal is delivered to a handler.
Status: Open.
Priority: Medium Low.
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. This has been put on the shelf for some time.
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.
Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
Status: Open
Priority: Low -- There is no plan to implement this.
Title: USER-SPACE WORK QUEUES
Description: There has been some use of work queues that has crept into some
user code. I am thinking of NxWidgets::CNxTimer. That timer
logic was originally implemented (correctly) using POSIX timers,
but was re-implemented using timed work.
The issue is that NxWidgets::CNxTimer is a user-space application
but the work queues are an OS internal feature. This will be a
problem for KERNEL builds. Hooks and definitions have been added
in include/nuttx/wqueue.h to support a user-space work queue, but
the corresponding logic has not been implemented.
The work queue logic will need to be moved from sched/ to libc/wqueue/
Status: Open. No work will probably be done until a functional KERNEL build
that includes NxWisges::CNxTimer is needed.
Priority: Medium Low for now
Title: INCOMPATIBILITES WITH execv() AND execl()
Description: Simplified 'execl()' and 'execv()' functions are provided by
NuttX. NuttX does not support processes and hence the concept
of overlaying a tasks process image with a new process image
does not make any sense. In NuttX, these functions are
wrapper functions that:
1. Call the non-standard binfmt function 'exec', and then
2. exit(0).
As a result, the current implementations of 'execl()' and
'execv()' suffer from some incompatibilities, the most
serious of these is that the exec'ed task will not have
the same task ID as the vfork'ed function. So the parent
function cannot know the ID of the exec'ed task.
Status: Open
Priority: Medium Low for now
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.
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
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).
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/)
^^^^^^^^^^^^^^^^^^^^^^^
Description: 'Standard' signals and signal actions are not supported.
(e.g., SIGINT, SIGCHLD, SIGSEGV, etc).
Priority: Low, required by standards but not so critical for an
embedded system.
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
Description: pthread_cancel(): Should implement cancellation points and
pthread_testcancel()
patacongo
committed
Title: PTHREAD_PRIO_PROTECT
Description: Extended pthread_mutexattr_setprotocol() suport PTHREAD_PRIO_PROTECT:
patacongo
committed
"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."
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
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."
patacongo
committed
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.
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().
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
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
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
NXFLATLDFLAGS2 = $(NXFLATLDFLAGS1) -T$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.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-gotoff.ld}
NXFLATLDSCRIPT=$(TOPDIR)/binfmt/libnxflat/gnu-nxflat-gotoff.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.
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
Title: TOOLCHAIN COMPATIBILITY PROBLEM
Descripton: The older 4.3.3 compiler generates GOTOFF relocations to the constant
strings, like:
.L3:
.word .LC0(GOTOFF)
.word .LC1(GOTOFF)
.word .LC2(GOTOFF)
.word .LC3(GOTOFF)
.word .LC4(GOTOFF)
Where .LC0, LC1, LC2, LC3, and .LC4 are the labels correponding to strings in
the .rodata.str1.1 section. One consequence of this is that .rodata must reside
in D-Space since it will addressed relative to the GOT (see the section entitled
"Read-Only Data in RAM" at
http://nuttx.org/Documentation/NuttXNxFlat.html#limitations).
The newer 4.6.3compiler generated PC relative relocations to the strings:
.L2:
.word .LC0-(.LPIC0+4)
.word .LC1-(.LPIC1+4)
.word .LC2-(.LPIC2+4)
.word .LC3-(.LPIC4+4)
.word .LC4-(.LPIC5+4)
This is good and bad. This is good because it means that .rodata.str1.1 can now
reside in FLASH with .text and can be accessed using PC-relative addressing.
That can be accomplished by simply moving the .rodata from the .data section to
the .text section in the linker script. (The NXFLAT linker script is located at
nuttx/binfmt/libnxflat/gnu-nxflat.ld).
This is bad because a lot of stuff may get broken an a lot of test will need to
be done. One question that I have is does this apply to all kinds of .rodata?
Or just to .rodata.str1.1?
Status: Open. Many of the required changes are in place but, unfortunately, not enough
go be fully functional. I think all of the I-Space-to-I-Space fixes are in place.
However, the generated code also includes PC-relative references to .bss which
just cannot be done.
Priority: Medium. The workaround for now is to use the older, 4.3.3 OABI compiler.
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. Nothing will probably be done until I have a platform
with two network interfaces that I need to support.
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. This is really part of the above issue.
Priority: Medium, The feature is not important, but it is important
for NuttX to resolve the architectural issues.
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. No work will probably be done until there is a specific
requirement for IPv6.
Title: LISTENING FOR UDP BROADCASTS
Description: Incoming UDP broadcast should only be accepted if listening on
INADDR_ANY(?)
Status: Open
Priority: Low
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. This is just a thought experiment. No changes are planned.
Title: STANDARDIZE ETHERNET DRIVER STATISTICS
Description: Need to standardize collection of statistics from network
drivers. apps/nshlib ifconfig command should present
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.
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.
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.
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.
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).
Title: USB HUB SUPPORT
Description: Add support for USB hubs
Status: Open
Priority: Low/Unknown. This is a feature enhancement.
patacongo
committed
o Libraries (libc/)
^^^^^^^^^^^^^^^^^
Title: SIGNED time_t
Description: The NuttX time_t is type uint32_t. I think this is consistent
with all standards and with normal usage of time_t. However,
according to Wikipedia, time_t is usually implemented as a
signed 32-bit value.
Status: Open
Priority: Very low unless there is some compelling issue that I do not
know about.
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
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().
patacongo
committed
UPDATE: There is growing functionality in libc/termios/ and in the
patacongo
committed
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.
Description: strftime() and other timing functions do not handle days of the week.
Status: Open
Priority: Low
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
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:
patacongo
committed
Description: This implementation of dtoa in libc/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
patacongo
committed
drivers/syslog, fs/fs_syslog.c, and libc/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
Description: At present, the CAN driver does not support the poll() method.
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.
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
Description: All drivers that support the poll method should also report
POLLHUP event when the driver is closedd.
Status: Open
Priority: Medium-Low
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.
Title: dup AND dup2 WILL NOT WORK ON FILES IN A MOUNTED VOLUME
Description: The current implementation of dup() and dup2() will only
work with open device drivers and sockets. It will not
work with open files in a file system. Support for dup'ing
open files on a mounted volume has not been implemented yet.
There is a stubbed out, partial implemenation in fs/fs_files.c.
In would perform the dup2() operation by re-opening the file
and setting the file pointer. The logic, however, would require
that we remember the (relative) path to the file in the mounted
volume for each open file.
An option might to add a dup() method to the file system
mountpoint interface.
A limitation that results from this is that you cannot
redirect I/O to an from and file.
Status: Open
Priority: High
o Graphics subystem (graphics/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
See also the NxWidgets TODO list file for related issues.
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.
patacongo
committed
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
patacongo
committed
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
patacongo
committed
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.
Title: P-CODES IN MEMORY UNTESTED
Description: Need APIs to verify execution of P-Code from memory buffer.
Status: Open
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.
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
Title: NUTTX CONFIGURATION TOOL
Description: Need a NuttX configuration tool. The number of configuration
settings has become quite large and difficult to manage manually.
patacongo
committed
Update: This task is essentially completed. But probably not for
all platforms and all features. When do we know that the feature
is complete and that we can switch to exclusive use of the tool?
Description: This effort is underway using MinGW-GCC and GNUWin32 tools
for (coreutils+make+grep+sed+uname). Current status:
1. configs/stm32f4discovery/winbuild - builds okay natively
2. configs/ez80f910200kitg - Can be reconfigured to build natively.
Requires some manual intervention to get a clean build.
See configs/ez80f910200kitg/README.txt.
Title: WINDOWS DEPENDENCY GENERATION
Description: Dependency generation is currently disabled when a Windows native
toolchain is used in a POSIX-like enviornment (like Cygwin). The
issue is that the Windows tool generates dependencies use Windows
path formatting and this fails with the dependency file (Make.dep)
is include). Perhaps 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