Newer
Older
Gregory Nutt
committed
NuttX TODO List (Last updated February 18, 2016)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This file summarizes known NuttX bugs, limitations, inconsistencies with
standards, things that could be improved, and ideas for enhancements. This
TODO list does not include issues associated with individual boar ports. See
altheso individual README.txt files in the configs/ sub-directories for
issues reated to each board port.
(3) Signals (sched/signal, arch/)
(2) pthreads (sched/pthread)
Gregory Nutt
committed
(0) Message Queues (sched/mqueue)
(6) Kernel/Protected Build
(3) C++ Support
(6) Binary loaders (binfmt/)
Gregory Nutt
committed
(4) USB (drivers/usbdev, drivers/usbhost)
(11) File system/Generic drivers (fs/, drivers/)
(1) Build system / Toolchains
Gregory Nutt
committed
(4) Linux/Cywgin simulation (arch/sim)
Gregory Nutt
committed
(3) Network Utilities (apps/netutils/)
(2) NuttShell (NSH) (apps/nshlib)
(1) System libraries apps/system (apps/system)
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.
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 PAGING 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 environment strings selected for
re-design would be required to implement this function and that
Description: timer_getoverrun() (sched/timer_getoverrun.c) is not implemented.
Status: Open
Priority: Low -- There is no plan to implement this.
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
patacongo
committed
Title: ISSUES WITH atexit() AND on_exit()
Description: These functions execute with the following bad properties:
patacongo
committed
1. They run with interrupts disabled,
2. They run in supervisor mode (if applicable), and
3. They do not obey any setup of PIC or address
environments. Do they need to?
The fix for all of these issues it to have the callbacks
run on the caller's thread (as with signal handlers).
Status: Open
Priority: Medium Low. This is an important change to some less
important interfaces. For the average user, these
functions are just fine the way they are.
Title: execv() AND vfork()
Description: There is a problem when vfork() calls execv() (or execl()) to
start a new application: When the parent thread calls vfork()
it receives and gets the pid of the vforked task, and *not*
the pid of the desired execv'ed application.
The same tasking arrangement is used by the standard function
posix_spawn(). However, posix_spawn uses the non-standard, internal
NuttX interface task_reparent() to replace the child's parent task
with the caller of posix_spawn(). That cannot be done with vfork()
because we don't know what vfork() is going to do.
Any solution to this is either very difficult or impossible without
an MMU.
Status: Open
Priority: Low (it might as well be low since it isn't going to be fixed).
patacongo
committed
Title: errno IS NOT SHARED AMONG THREADS
Description: In NuttX, the errno value is unique for each thread. But for
bug-for-bug compatibility, the same errno should be shared by
the task and each thread that it creates. It is *very* easy
to make this change: Just move the pterrno field from
struct tcb_s to struct task_group_s. However, I am still not
sure if this should be done or not.
Status: Closed. The existing solution is better (although its
incompatibilities could show up in porting some code).
patacongo
committed
Priority: Low
Title: REMOVE TASK_DELETE
Description: Need to remove or fix task delete. This interface is non-
standard and not safe. Arbitrary deleting tasks can cause
serious problems such as memory leaks. Better to remove it
than to retain it as a latent bug.
Currently used within the OS and also part of the
implementation of pthread_cancel() and task_restart() (which
should also go for the same reasons). It is used in
NxWM::CNxConsole to terminate console tasks and also in
apps/netutils/thttpd to kill CGI tasks that timeout.
Status: Open
Priority: Low and not easily removable.
Title: RELEASE SEMAPHORES HELD BY CANCELED THREADS:
Description: Commit: fecb9040d0e54baf14b729e556a832febfe8229e: "In
case a thread is doing a blocking operation (e.g. read())
on a serial device, while it is being terminated by
pthread_cancel(), then uart_close() gets called, but
the semaphore (dev->recv.sem in the above example) is
still blocked.
"This means that once the serial device is opened next
time, data will arrive on the serial port (and driver
interrupts handled as normal), but the received characters
never arrive in the reader thread.
This patch addresses the problem by re-initializing the
semaphores on the last uart_close() on the device."
Yahoo! Groups message 7726: "I think that the system
should be required to handle pthread_cancel safely in
all cases. In the NuttX model, a task is like a Unix
process and a pthread is like a Unix thread. Cancelling
threads should always be safe (or at least as unsafe) as
under Unix because the model is complete for pthreads...
specific to the serial driver. I could also implement
logic to release all semaphores held by a thread when
it exits -- but only if priority inheritance is enabled;
because only in that case does the code have any memory
of which threads actually hold the semaphore.
"The patch I just incorporated is also insufficient. It
works only if the serial driver is shut down when the
thread is cancelled. But what if there are other open
references to the driver? Then the driver will not be
shut down, the semaphores will not be re-initialized, and
the semaphore counts will still be off by one.
"I think that the system needs to automatically release any
semaphores held by a thread being killed asynchronously?
It seems necessary to me."
UPDATE; The logic enabled when priority inheritance is
enabled for this purpose is insufficient. It provides
hooks so that given a semaphore it can traverse all
holders. What is needed would be logic so that given
a task, you can traverse all semaphores held by the task,
releasing each semaphore cound held by the exiting task.
Nothing like this exists now so that solution is not
imminent.
UPDATE: The basic fix to release the semaphore count if
a thread is killed via pthread_cancel() or task_delete()
has been implemented (2014-12-13). See the new file:
sched/semaphore/sem_recover.c However, the general
issue of freeing semaphores when a thread exists still
exists.
Status: Open
Priority: Medium-ish
Title: SCALABILITY
Description: Task control information is retained in simple lists. This
is completely appropriate for small embedded systems where
the number of tasks, N, is relatively small. Most list
operations are O(N). This could become as issue if N gets
very large.
In that case, these simple lists should be replaced with
something more performant such as a balanced tree in the
case of ordered lists. Fortunately, most internal lists are
hidden behind simple accessor functions and so the internal
data structures can be changed if need with very little impact.
Gregory Nutt
committed
Explicity refereence to the list strucutre are hidden behnid
the macro this_task().
Status: Open
Priority: Low. Things are just the way that we want them for the way
that NuttX is used today.
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.
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
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).
Updated 2016-06-25:
For processors with an MMU (Memory Management Unit), NuttX can be
built in a kernel mode. In that case, each process will have a
local copy of its heap (filled with sbrk()) and when the process
exits, its local heap will be destroyed and the underlying page
memory is recovered.
So in this case, NuttX work just link Linux or or *nix systems:
All memory allocated by processes or threads in processes will
be recovered when the process exists.
But not for the flat memory build. In that case, the issues
above do apply. There is no safe way to recover the memory in
that case (and even if there were, the additional overhead would
not be acceptable on most platforms).
This does not prohibit anyone from creating a wrapper for malloc()
and an atexit() callback that frees memory on task exit. People
are free and, in fact, encouraged, to do that. However, since
it is inherently unsafe, I would never incorporate anything
like that into NuttX.
Priority: Medium/Low, a good feature to prevent memory leaks but would
have negative impact on memory usage and code size.
o Signals (sched/signal, arch/)
Description: 'Standard' signals and signal actions are not supported.
(e.g., SIGINT, SIGSEGV, etc).
Priority: Low, required by standards but not so critical for an
embedded system.
Description: Implementation of support for support for SIGEV_THREAD is available
only in the FLAT build mode because it uses the OS work queues to
perform the callback. The alternative for the PROTECTED and KERNEL
builds would be to create pthreads in the user space to perform the
callbacks. That is not a very attractive solution due to performance
issues. It would also require some additional logic to specify the
TCB of the parent so that the pthread could be bound to the correct
group.
There is also some user-space logic in libc/aio/lio_listio.c. That
logic could use the user-space work queue for the callbacks.
Status: Low, there are alternative designs. However, these features
are required by the POSIX standard.
Priority: Low for now
Title: SIGNAL NUMBERING
Description: In signal.h, the range of valid signals is listed as 0-31. However,
in many interfaces, 0 is not a valid signal number. The valid
signal number should be 1-32. The signal set operations would need
to map bits appropriately.
Status: Open
Priority: Low. Even if there are only 31 usable signals, that is still a lot.
o pthreads (sched/pthreads)
Description: pthread_cancel(): Should implement cancellation points and
pthread_testcancel()
patacongo
committed
Title: PTHREAD_PRIO_PROTECT
Description: Extended pthread_mutexattr_setprotocol() support 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."
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
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 pthread 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
Gregory Nutt
committed
o Message Queues (sched/mqueue)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
o Kernel/Protected Build
^^^^^^^^^^^^^^^^^^^^^^
Gregory Nutt
committed
Title: NSH PARTITIONING.
Description: There are issues with several NSH commands in the NuttX kernel
and protected build modes (where NuttX is built as a monolithic
kernel and user code must trap into the protected kernel via
syscalls). The current NSH implementation has several commands
that call directly into kernel internal functions for which
there is no syscall available. The commands cause link failures
in the kernel/protected build mode and must currently be disabled.
Gregory Nutt
committed
Here are known problems that must be fixed:
COMMAND KERNEL INTERFACE(s)
-------- ----------------------------------------------
mkfatfs mkfatfs
mkrd ramdisk_register()
Gregory Nutt
committed
The busybox mkfatfs does not involve any OS calls; it does
its job by simply opening the block driver (using open/xopen)
and modifying it with write operations. See:
http://git.busybox.net/busybox/tree/util-linux/mkfs_vfat.c
Gregory Nutt
committed
Priority: Medium/High -- the kernel build configuration is not fully fielded
Title: NxTERM PARTITIONING.
Description: NxTerm is implemented (correctly) as a driver that resides
Gregory Nutt
committed
in the nuttx/ directory. However, the user interfaces must be
moved into a NuttX library or into apps/. Currently
applications calls to the NxTerm user interfaces are
Gregory Nutt
committed
undefined.
Gregory Nutt
committed
Priority: Medium
Title: C++ CONSTRUCTORS HAVE TOO MANY PRIVILEGES (PROTECTED MODE)
Description: When a C++ ELF module is loaded, its C++ constructors are called
via sched/task_starthook.c logic. This logic runs in protected mode.
The is a security hole because the user code runs with kernel-
Gregory Nutt
committed
privileges when the constructor executes.
Destructors likely have the opposite problem. The probably try to
execute some kernel logic in user mode? Obviously this needs to
be investigated further.
Status: Open
Priority: Low (unless you need build a secure C++ system).
Title: TOO MANY SYSCALLS
Description: There are a few syscalls that operate very often in user space.
Since syscalls are (relatively) time consuming this could be
a performance issue. Here is some numbers that I collected
sem_post - 18% of syscalls
sem_wait - 18% of syscalls
getpid - 59% of syscalls
--------------------------
95% of syscalls
Obviously system performance could be improved greatly by simply
optimizing these functions so that they do not need to system calls
so frequently. getpid() is (I believe) part of the re-entrant
semaphore logic. Something like TLS might be used to retain the
thread's ID locally.
Linux, for example, has functions call up() and down(). up()
increments the semaphore count but does not call into the kernel
unless incrementing the count unblocks a task; similarly, down
decrements the count and does not call into the kernel unless
the count becomes negative the caller must be blocked.
"I am thinking that there should be a "magic" global, user-accessible
variable that holds the PID of the currently executing thread;
basically the PID of the task at the head of the ready-to-run list.
This variable would have to be reset each time the head of the ready-
to-run list changes.
"Then getpid() could be implemented in user space with no system call
by simply reading this variable.
"This one would be easy: Just a change to include/nuttx/userspace.h,
configs/*/kernel/up_userspace.c, libc/, sched/sched_addreadytorun.c, and
sched/sched_removereadytorun.c. That would eliminate 59% of the syscalls."
Update:
This is probably also just a symptom of the OS test that does mostly
console output. The requests for the pid() are part of the
implementation of the I/O's re-entrant semaphore implementation and
would not be an issue in the more general case.
Status: Open
Priority: Low-Medium. Right now, I do not know if these syscalls are a
real performance issue or not. The above statistics were collected
from a an atypical application (the OS test), and does an excessive
amount of console output. There is probably no issue with more typical
embedded applications.
Title: SECURITY ISSUES
Description: In the current designed, the kernel code calls into the user-space
allocators to allocate user-space memory. It is a security risk to
call into user-space in kernel-mode because that could be exploited
to gain control of the system. That could be fixed by dropping to
user mode before trapping into the memory allocators; the memory
allocators would then need to trap in order to return (this is
already done to return from signal handlers; that logic could be
renamed more generally and just used for a generic return trap).
Another place where the system calls into the user code in kernel
mode is work_usrstart() to start the user work queue. That is
another security hole that should be plugged.
Status: Open
Priority: Low (unless security becomes an issue).
Title: MICRO-KERNEL
Description: The initial kernel build cut many interfaces at a very high level.
Gregory Nutt
committed
The resulting monolithic kernel is then rather large. It would
not be a prohibitively large task to reorganize the interfaces so
that NuttX is built as a micro-kernel, i.e., with only the core
OS services within the kernel and with other OS facilities, such
Gregory Nutt
committed
as the file system, message queues, etc., residing in user-space
and to interfacing with those core OS facilities through traps.
Status: Open
Priority: Low. This is a good idea and certainly an architectural
improvement. However, there is no strong motivation now do
do that partitioning work.
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 a hold of the compilers definition of size_t.
Gregory Nutt
committed
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
Title: STATIC CONSTRUCTORS AND MULTITASKING
Description: The logic that calls static constructors operates on the main
thread of the initial user application task. Any static
constructors that cache task/thread specific information such
as C streams or file descriptors will not work in other tasks.
See also UCLIBC++ AND STATIC CONSTRUCTORS below.
Status: Open
Priority: Low and probably will not changed. In these case, there will
need to be an application specific solution.
Title: UCLIBC++ AND STATIC CONSTRUCTORS
uClibc++ was designed to work in a Unix environment with
processes and with separately linked executables. Each process
has its own, separate uClibc++ state. uClibc++ would be
instantiated like this in Linux:
1) When the program is built, a tiny start-up function is
included at the beginning of the program. Each program has
its own, separate list of C++ constructors.
2) When the program is loaded into memory, space is set aside
for uClibc's static objects and then this special start-up
routine is called. It initializes the C library, calls all
of the constructors, and calls atexit() so that the destructors
will be called when the process exits.
In this way, you get a per-process uClibc++ state since there
is per-process storage of uClibc++ global state and per-process
initialization of uClibc++ state.
Compare this to how NuttX (and most embedded RTOSs) would work:
1) The entire FLASH image is built as one big blob. All of the
constructors are lumped together and all called together at
one time.
This, of course, does not have to be so. We could segregate
constructors by some criteria and we could use a task start
up routine to call constructors separately. We could even
use ELF executables that are separately linked and already
have their constructors separately called when the ELF
executable starts.
But this would not do you very much good in the case of
uClibc++ because:
2) NuttX does not support processes, i.e., separate address
environments for each task. As a result, the scope of global
data is all tasks. Any change to the global state made by
one task can effect another task. There can only one
uClibc++ state and it will be shared by all tasks. uClibc++
apparently relies on global instances (at least for cin and
cout) there is no way to to have any unique state for any
"task group".
[NuttX does not support processes because in order to have
true processes, your hardware must support a memory management
unit (MMU) and I am not aware of any mainstream MCU that has
an MMU (or, at least an MMU that is capable enough to support
processes).]
NuttX does not have processes, but it does have "task groups".
See http://www.nuttx.org/doku.php?id=wiki:nxinternal:tasksnthreads.
A task group is the task plus all of the pthreads created by
the task via pthread_create(). Resources like FILE streams
are shared within a task group. Task groups are like a poor
man's process.
This means that if the uClibc++ static classes are initialized
by one member of a task group, then cin/cout should work
correctly with all threads that are members of task group. The
destructors would be called when the final member of the task
group exists (if registered via atexit()).
So if you use only pthreads, uClibc++ should work very much like
it does in Linux. If your NuttX usage model is like one process
with many threads then you have Linux compatibility.
If you wanted to have uClibc++ work across task groups, then
uClibc++ and NuttX would need some extensions. I am thinking
along the lines of the following:
1) There is a per-task group storage are within the RTOS (see
include/nuttx/sched.h). If we add some new, non-standard APIs
Gregory Nutt
committed
then uClibc++ could get access to per-task group storage (in
the spirit of pthread_getspecific() which gives you access to
per-thread storage).
2) Then move all of uClibc++'s global state into per-task group
storage and add a uClibc++ initialization function that would:
a) allocate per-task group storage, b) call all of the static
constructors, and c) register with atexit() to perform clean-
up when the task group exits.
That would be a fair amount of effort. I don't really know what
the scope of such an effort would be. I suspect that it is not
large but probably complex.
NOTES:
1) See STATIC CONSTRUCTORS AND MULTITASKING
2) To my knowledge, only some uClibc++ ofstream logic is
sensitive to this. All other statically initialized classes
seem to work OK across different task groups.
Status: Open
Priority: Low. I have no plan to change this logic now unless there is
some strong demand to do so.
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.
patacongo
committed
Update: 13-27-1, tests/mutex crashed with a memory corruption
problem the last time that I ran it.
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 Documentation/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
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.
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
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.
Title: LISTENING FOR UDP BROADCASTS
Description: Incoming UDP broadcast should only be accepted if listening on
INADDR_ANY(?)
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: POLL/SELECT ON TCP/UDP SOCKETS NEEDS READ-AHEAD
Description: poll()/select() only works for availability of buffered TCP/UDP
read data (when read-ahead is enabled). The way writing is
handled in the network layer, all sockets must wait when send and
cannot be notified 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 nonblocking operations only (1) for TCP/IP non-
blocking read operations when read-ahead buffering is
enabled, (2) TCP/IP accept() operations when TCP/IP
connection backlog is enabled, (2) UDP/IP read() operations
when UDP read-ahead is enabled, and (3) non-blocking
operations on Unix domain sockets.
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: 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: CLOSED CONNECTIONS IN THE BACKLOG
If a connection is backlogged but accept() is not called quickly, then
that connection may time out. How should this be handled? Should the
connection be removed from the backlog if it is times out or is closed?
Or should it remain in the backlog with a status indication so that accept()
can fail when it encounteres the invalid connection?
Gregory Nutt
committed
Priority: Medium. Important on slow applications that will not accept
connections promptly.
Description: Too many Ethernet drivers do interrupt-level processing with
the network stack. The network stack supports either interrupt
level processing or normal task level processing (depending on
CONFIG_NET_NOINTS). This is really a very bad use of CPU
Gregory Nutt
committed
resources; All of the network stack processing should be
modified to use a work queue (and, all use of CONFIG_NET_NOINTS=n
should be eliminated). This applies to almost all Ethernet
drivers:
Gregory Nutt
committed
ARCHITECTURE CONFIG_NET_NOINTS? ADDRESS FILTER SUPPORT?
C5471 NO NO
STM32 YES YES
Gregory Nutt
committed
TIVA ----------------------- ------
LM3S NO NO
TM4C YES YES
eZ80 NO NO
LPC17xx YES YES (not tested)
Gregory Nutt
committed
DMxxx NIC NO NO
PIC32 NO NO
RGMP ??? ???
SAM3/4 YES YES
SAMA5D ----------------------- ------
EMACA NO YES (not tested)
EMACB YES YES
GMAC NO YES (not tested)
SAMV7 YES YES
SIM N/A (No interrupts) NO
The general outline of how this might be done is included in
drivers/net/skeleton.c
Status: Open
Priority: Pretty high if you want a well behaved system.
Title: UDP MULTICAST RECEPTION
Description: The logic in udp_input() expects either a single receive socket or
none at all. However, multiple sockets should be capable of
receiving a UDP datagram (multicast reception). This could be
handled easily by something like:
for (conn = NULL; conn = udp_active (pbuf, conn); )
If the callback logic that receives a packet responds with an
outgoing packet, then it will over-write the received buffer,
however. recvfrom() will not do that, however. We would have
to make that the rule: Recipients of a UDP packet must treat
the packet as read-only.
Status: Open
Priority: Low, unless your logic depends on that behavior.
Gregory Nutt
committed
Title: NETWORK WON'T STAY DOWN
Description: If you enable the NSH network monitor (CONFIG_NSH_NETINIT_MONITOR)
then the NSH 'ifdown' command is broken. Doing 'nsh> ifconfig eth0'
will, indeed, bring the network down. However, the network monitor
notices the change in the link status and will bring the network
back up. There needs to be some kind of interlock between
cmd_ifdown() and the network monitor thread to prevent this.
Status: Open
Priority: Low, this is just a nuisance in most cases.
Title: FIFO CLEAN-UP AFTER CLOSING UNIX DOMAIN DATAGRAM SOCKET
Description: FIFOs are used as the IPC underlying all local Unix domain
sockets. In NuttX, FIFOs are implemented as device drivers
(not as a special FIFO files). The FIFO device driver is
instantiated when the Unix domain socket communications begin
and will automatically be released when (1) the driver is
unlinked and (2) all open references to the driver have been
closed. But there is no mechanism in place now to unlink the
FIFO when the Unix domain datagram socket is no longer used.
The primary issue is timing.. the FIFO should persist until
it is no longer needed. Perhaps there should be a delayed
call to unlink() (using a watchdog or the work queue). If
the driver is re-opened, the delayed unlink could be
cancelled? Needs more thought.
NOTE: This is not an issue for Unix domain streams sockets:
The end-of-life of the FIFO is well determined when sockets
are disconnected and support for that case is fully implemented.
Status: Open
Priority: Low for now because I don't have a situation where this is a
problem for me. If you use the same Unix domain paths, then
it is not a issue; in fact it is more efficient if the FIFO
devices persist. But this would be a serious problem if,
for example, you create new Unix domain paths dynamically.
In that case you would effectively have a memory leak and the
number of FIFO instances grow.
Title: TCP IPv4-MAPPED IPv6 ADDRESSES
Description: The UDP implementation in net/udp contains support for Hybrid
dual-stack IPv6/IPv4 implementations that utilize a special
class of addresses, the IPv4-mapped IPv6 addresses. You can
see that UDP implementation in:
udp_callback.c:
ip6_map_ipv4addr(ipv4addr,
udp_send.c:
ip6_is_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr)))
ip6_is_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr))
in_addr_t raddr = ip6_get_ipv4addr((FAR struct in6_addr*)conn->u.ipv6.raddr);
There is no corresponding support for TCP sockets.
Status: Open
Priority: Low. I don't know of any issues now, but I am sure that
someone will encounter this in the future.
Title: MISSING netdb INTERFACES
Description: There is no implementation for many netdb interfaces such as
getaddrinfo(), freeaddrinfo(), getnameinfo(), etc.
Status: Open
Priority: Low
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.
Gregory Nutt
committed
If queuing of stall requests is supported by DCD then this workaround
is not required. In this case, (1) the stall is not sent until all
write requests preceding the stall request are sent, (2) the stall is
sent, and then after the stall is cleared, (3) all write requests
queued after the stall are sent.
See, for example, the queuing of pending stall requests in the SAM3/4
UDP driver at arch/arm/src/sam34/sam_udp.c. There the logic is do this
is implemented with a normal request queue, a pending request queue, a
stall flag and a stall pending flag:
1) If the normal request queue is not empty when the STALL request is