Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
NuttX RTOS
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Deploy
Releases
Container Registry
Model registry
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
f4grx
NuttX RTOS
Commits
82cd2717
Commit
82cd2717
authored
8 years ago
by
Gregory Nutt
Browse files
Options
Downloads
Patches
Plain Diff
Update TODO list
parent
ac9a11d9
No related branches found
Branches containing commit
No related tags found
Tags containing commit
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
TODO
+43
-9
43 additions, 9 deletions
TODO
with
43 additions
and
9 deletions
TODO
+
43
−
9
View file @
82cd2717
...
...
@@ -9,7 +9,8 @@ issues related to each board port.
nuttx/:
(15) Task/Scheduler (sched/)
(13) Task/Scheduler (sched/)
(3) SMP
(1) Memory Management (mm/)
(1) Power Management (drivers/pm)
(3) Signals (sched/signal, arch/)
...
...
@@ -255,7 +256,7 @@ o Task/Scheduler (sched/)
a holder of the semaphore. Normally, a task is removed from
the holder list when it finally releases the semaphore via
sem_post().
However, TASK A never calls sem_post(sem) so it becomes
*permanently* a holder of the semaphore and may have its
priority boosted at any time when any other task tries to
...
...
@@ -304,7 +305,9 @@ o Task/Scheduler (sched/)
Priority: Low. Things are just the way that we want them for the way
that NuttX is used today.
Title: SMP ISSUES
o SMP
^^^
Title: SMP ISSUES WITH task_restart() AND task_delete()
Description: The interface task_restart() (and probably task_delete()) are
not usable in the SMP configuration in the current design. In
the non-SMP case, these are relatively simple: If the task is
...
...
@@ -330,9 +333,39 @@ o Task/Scheduler (sched/)
The task_restart() test is also disabled in apps/examples/ostest
in this configuration. task_delete(), on the other hand, is
built (but probably should not be).
Status: Open
Priority: Low. I do not plan to do anything with this in the near future.
Title: SMP AND SIGNAL ACTIONS
Description: Suppose a task task is running on CPU1 and it is signaled from
another task running on CPU0. How does the signal handler run
on CPU1? I think it does not; I think that the signal will be
lost. I think all testing up to this point has used a task
waiting for a signal vs. a running task receiving a signal.
This case has never been tested, but I suspect an issues.
Here is why... this is the signal handling sequence:
- sigueue() will set up the siginfo data structure and call
sig_dipatch().
- sig_tcbdispach() or group_signal() depending on the
configuration. Let's assume the simpler sig_tcbdispatch().
- sig_tcbdispatch() will call queue the signal action (via
sig_queueaction()) and then call the architecture-specific
up_schedule_signaction set up the invoke the signal handler
(for example in arch/arm/src/armv7-m/up_schedulesigaction.c).
- sig_queueaction() will assume that the other task is not
running and will simply modify data structures in the TCB.
This, will have no effect if the task is running and the
signal action will not be performed.
This is really a variant of the problem described above under
"SMP ISSUES WITH task_restart() AND task_delete()" and the
same proposed solution applies: Call up_cpu_pause() to stop
all other CPUs before up_schedule_signaction runs.
Status: Open
Priority: High. This must be fixed.
Title: SPINLOCKS AND DATA CACHES
Description: If spinlocks are used in a system with a data cache, then there
may be a problem with cache coherency in some CPU architectures:
...
...
@@ -346,12 +379,12 @@ o Task/Scheduler (sched/)
unless the spinlocks were made to be the same size as one cache
line.
The better option is to add compiler independent "ornmentation"
The better option is to add compiler independent "orn
a
mentation"
to the spinlock so that the spinlocks are all linked together
into a separate, non-cacheable memory regions. Because of
region aligment and minimum region mapping sizes
. T
his
w
ould
work in systems that have both data cache and either an MPU or
an MMU.
region aligment and minimum region mapping sizes
t
his
c
ould
still be wasteful of memory. This would work in systems that
have both data cache and either an MPU or
an MMU.
Status: Open
Priority: High. spinlocks, and hence SMP, will not work on such systems
without this change.
...
...
@@ -1360,8 +1393,8 @@ o USB (drivers/usbdev, drivers/usbhost)
Status: Open
Priority: Medium-Low unless you really need host CDC/ACM support.
o Libraries (libc/)
^^^^^^^^^^^^^^^^^
o Libraries (libc/
, libm/
)
^^^^^^^^^^^^^^^^^
^^^^^^^
Title: SIGNED time_t
Description: The NuttX time_t is type uint32_t. I think this is consistent
...
...
@@ -2080,3 +2113,4 @@ o Other Applications & Tests (apps/examples/)
the artifact is larger.
Status: Open
Priority: Medium.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment