Newer
Older
commands, but is non-standard because: (1) It does not support IGMPv3, and
(2) it looks up drivers by their device name (e.g., "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 encounters the invalid connection?
Gregory Nutt
committed
Priority: Medium. Important on slow applications that will not accept
connections promptly.
Title: IPv6 REQUIRES ADDRESS FILTER SUPPORT
Description: IPv6 requires that the Ethernet driver support NuttX address
filter interfaces. Several Ethernet drivers do support there,
however. Others support the address filtering interfaces but
have never been verifed:
C5471, LM3S, ez80, DM0x90 NIC, PIC: Do not support address
filtering.
Kinetis, LPC17xx, LPC43xx: Untested address filter support
Priority: Pretty high if you want a to use IPv6 on these platforms.
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
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
Title: ETHERNET WITH MULTIPLE LPWORK THREADS
Description: Recently, Ethernet drivers were modified to support multiple
work queue structures. The question was raised: "My only
reservation would be, how would this interact in the case of
having CONFIG_STM32_ETHMAC_LPWORK and CONFIG_SCHED_LPNTHREADS
> 1? Can it be guaranteed that one work item won't be
interrupted and execution switched to another? I think so but
am not 100% confident."
I suspect that you right. There are probably vulnerabilities
in the CONFIG_STM32_ETHMAC_LPWORK with CONFIG_SCHED_LPNTHREADS
> 1 case. But that really doesn't depend entirely upon the
change to add more work queue structures. Certainly with only
work queue structure you would have concurrent Ethernet
operations in that multiple LP threads; just because the work
structure is available, does not mean that there is not dequeued
work in progress. The multiple structures probably widens the
window for that concurrency, but does not create it.
The current Ethernet designs depend upon a single work queue to
serialize data. In the case of muliple LP threads, some
additional mechanism would have to be added to enforce that
serialization.
Gregory Nutt
committed
NOTE: Most drivers will call net_lock() and net_unlock() around
the critical portions of the driver work. In that case, all work
will be properly serialized. This issue only applies to drivers
that may perform operations that require protection outside of
the net_lock'ed region. Sometimes, this may require extending
the netlock() to be beginning of the driver work function.
Status: Open
Priority: High if you happen to be using Ethernet in this configuration.
Title: REPARTITION DRIVER FUNCTIONALITY
Description: Every network driver performs the first level of packet decoding.
It examines the packet header and calls ipv4_input(), ipv6_input().
icmp_input(), etc. as appropriate. This is a maintenance problem
because it means that any changes to the network input interfaces
affects all drivers.
A better, more maintainable solution would use a single net_input()
function that would receive all incoming packets. This function
would then perform that common packet decoding logic that is
currently implemented in every network driver.
Status: Open
Priority: Low. Really just as aesthetic maintainability issue.
Title: BROADCAST WITH MULTIPLE NETWORK INTERFACES
Description: There is currently no mechanism to send a broadcast packet
out through several network interfaces. Currently packets
can be sent to only one device. Logic in netdev_findby_ipvXaddr()
currently just selects the first device in the list of
devices; only that device will receive broadcast packets.
Status: Open
Priority: High if you require broadcast on multiple networks. There is
no simple solution known at this time, however. Perhaps
netdev_findby_ipvXaddr() should return a list of devices rather
than a single device? All upstream logic would then have to
deal with a list of devices. That would be a huge effect and
certainly doesn't dount as a "simple solution".
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 the DCD then this workaround
Gregory Nutt
committed
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
received, the stall pending flag is set.
2) If addition write requests are received while the stall pending flag
is set (or while waiting for the stall to be sent), those write requests
go into the pending queue.
3) When the normal request queue empties successful and all of the write
transfers complete, the STALL is sent. The stall pending flag is
cleared and the stall flag is set. Now the endpoint is really stalled.
4) After the STALL is cleared (via the Clear Feature SETUP), the pending
request queue is copied to the normal request queue, the stall flag is
cleared, and normal write request processing resumes.
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.
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
Here is an overview of the required changes:
New two buffers in driver structure:
1. The existing EP0 setup request buffer (ctrlreq, 8 bytes)
2. A new EP0 data buffer to driver state structure (ep0data,
max packetsize)
Add a new state:
3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT)
General logic flow:
1. When an EP0 SETUP packet is received:
- Read the request into EP0 setup request buffer (ctrlreq,
8 bytes)
- If this is an OUT request with data length, set the EP0
state to EP0STATE_SETUP_OUT and wait to receive data on
EP0.
- Otherwise, the SETUP request may be processed now (or,
in the case of the F4 driver, at the conclusion of the
SETUP phase).
2. When EP0 the EP0 OUT DATA packet is received:
- Verify state is EP0STATE_SETUP_OUT
- Read the request into the EP0 data buffer (ep0data, max
packet size)
- Now process the previously buffered SETUP request along
with the OUT data.
3. When the setup packet is dispatched to the class driver,
the OUT data must be passed as the final parameter in the
call.
Update 2013-9-2: The new USB device-side driver for the SAMA5D3
correctly supports OUT SETUP data following the same design as
per above.
Update 2013-11-7: David Sidrane has fixed with issue with the
STM32 F1 USB device driver. Still a few more to go before this
can be closed out.
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
Title: IMPROVED USAGE of STM32 USB RESOURCES
Description: The STM32 platforms use a non-standard, USB host peripheral
that uses "channels" to implement data transfers the current
logic associates each channel with an pipe/endpoint (with two
channels for bi-directional control endpoints). The OTGFS
peripheral has 8 channels and the OTGHS peripheral has 12
channels.
This works okay until you add a hub and try connect multiple
devices. A typical device will require 3-4 pipes and, hence,
4-5 channels. This effectively prevents using a hub with the
STM32 devices. This also applies to the EFM32 which uses the
same IP.
It should be possible to redesign the STM32 F4 OTGHS/OTGFS and
EFM32 host driver so that channels are dynamically assigned to
pipes as needed for individual transfers. Then you could have
more "apparent" pipes and make better use of channels.
Although there are only 8 or 12 channels, transfers are not
active all of the time on all channels so it ought to be
possible to have an unlimited number of "pipes" but with no
more than 8 or 12 active transfers.
Status: Open
Priority: Medium-Low
Description: A CDC/ACM host class driver has been added. This has been
testing by running the USB CDC/ACM host on an Olimex
LPC1766STK and using the configs/stm3210e-eval/usbserial
configuration (using the CDC/ACM device side driver). There
are several unresolved issues that prevent the host driver
from being usable:
Gregory Nutt
committed
- The driver works fine when configured for reduced or bulk-
only protocol on the Olimex LPC1766STK.
- Testing has not been performed with the interrupt IN channel
enabled (ie., I have not enabled FLOW control nor do I have
a test case that used the interrupt IN channel). I can see
that the polling for interrupt IN data is occurring
initially.
- I test for incoming data by doing 'nsh> cat /dev/ttyACM0' on
the Olimex LPC1766STK host. The bulk data reception still
works okay whether or not the interupt IN channel is enabled.
If the interrupt IN channel is enabled, then polling of that
channel appears to stop when the bulk in channel becomes
active.
- The RX reception logic uses the low priority work queue.
However, that logic never returns and so blocks other use of
the work queue thread. This is probably okay but means that
the RX reception logic probably should be moved to its own
dedicated thread.
Gregory Nutt
committed
- I get crashes when I run with the STM32 OTGHS host driver.
Apparently the host driver is trashing memory on receipt
of data.
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
UPDATE: This behavior needs to be retested with:
commit ce2845c5c3c257d081f624857949a6afd4a4668a
Author: Janne Rosberg <janne.rosberg@offcode.fi>
Date: Tue Mar 7 06:58:32 2017 -0600
usbhost_cdcacm: fix tx outbuffer overflow and remove now
invalid assert
commit 3331e9c49aaaa6dcc3aefa6a9e2c80422ffedcd3
Author: Janne Rosberg <janne.rosberg@offcode.fi>
Date: Tue Mar 7 06:57:06 2017 -0600
STM32 OTGHS host: stm32_in_transfer() fails and returns NAK
if a short transfer is received. This causes problems from
class drivers like CDC/ACM where short packets are expected.
In those protocols, any transfer may be terminated by sending
short or NUL packet.
commit 0631c1aafa76dbaa41b4c37e18db98be47b60481
Author: Gregory Nutt <gnutt@nuttx.org>
Date: Tue Mar 7 07:17:24 2017 -0600
STM32 OTGFS, STM32 L4 and F7: Adapt Janne Rosberg's patch to
STM32 OTGHS host to OTGFS host, and to similar implements for
L4 and F7.
Gregory Nutt
committed
- The SAMA5D EHCI and the LPC31 EHCI drivers both take semaphores
in the cancel method. The current CDC/ACM class driver calls
the cancel() method from an interrupt handler. This will
cause a crash. Those EHCI drivers should be redesigned to
permit cancellation from the interrupt level.
Gregory Nutt
committed
Most of these problems are unique to the Olimex LPC1766STK
DCD; some are probably design problems in the CDC/ACM host
driver. The bottom line is that the host CDC/ACM driver is
still immature and you could experience issues in some
configurations if you use it.
That all being said, I know of know no issues with the current
CDC/ACM driver on the Olimex LPC1766STK platform if the interrupt
IN endpoint is not used, i.e., in "reduced" mode. The only loss
of functionality is output flow control.
UPDATE: The CDC/ACM class driver may also now be functional on
the STM32. That needs to be verified.
Status: Open
Priority: Medium-Low unless you really need host CDC/ACM support.
o Libraries (libc/, libm/)
^^^^^^^^^^^^^^^^^^^^^^^^
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 array of pointers.
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: 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: 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 replace 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: ??
Gregory Nutt
committed
Description: Only the %f floating point format is supported. Others are
accepted but treated like %f.
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).
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
Title: LIBM INACCURACIES
Description: "..if you are writing something like robot control or
inertial navigation system for aircraft, I have found
that using the toolchain libmath is only safe option.
I ported some code for converting quaternions to Euler
angles to NuttX for my project and only got it working
after switching to newlib math library.
"NuttX does not fully implement IEC 60559 floating point
from C99 (sections marked [MX] in OpenGroup specs) so if
your code assumes that some function, say pow(), actually
behaves right for all the twenty or so odd corner cases
that the standards committees have recently specified,
you might get surprises. I'd expect pow(0.0, 1.0) to
return 0.0 (as zero raised to any positive power is
well-defined in mathematics) but I get +Inf.
"NuttX atan2(-0.0, -1.0) returns +M_PI instead of correct
-M_PI. If we expect [MX] functionality, then atan2(Inf, Inf)
should return M_PI/4, instead NuttX gives NaN.
"asin(2.0) does not set domain error or return NaN. In fact
it does not return at all as the loop in it does not
converge, hanging your app.
"There are likely many other issues like these as the Rhombus
OS code has not been tested or used that much. Sorry for not
providing patches, but we found it easier just to switch the
math library."
Ref: https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/7805
UPDATE: 2015-09-01: A fix for the noted problems with asin()
has been applied.
Gregory Nutt
committed
2016-07-30: Numerous fixes and performance improvements from
David Alessio.
Status: Open
Priority: Low for casual users but clearly high if you need care about
these incorrect corner case behaviors in the math libraries.
Gregory Nutt
committed
Title: REPARTITION LIBC FUNCTIONALITY
Description: There are many things implemented within the kernel (for example
under sched/pthread) that probably should be migrated in the
C library where it belongs.
I would really like to see a little flavor of a micro-kernel
at the OS interface: I would like to see more primitive OS
system calls with more higher level logic in the C library.
One awkward thing is the incompatibility of KERNEL vs FLAT
builds: In the kernel build, it would be nice to move many
of the thread-specific data items out of the TCB and into
the process address environment where they belong. It is
difficult to make this compatible with the FLAT build,
however.
Status: Open
o File system / Generic drivers (fs/, drivers/)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
NOTE: The NXFFS file system has its own TODO list at nuttx/fs/nxffs/README.txt
Title: MISSING FILE SYSTEM FEATURES
Description: Implement missing file system features:
chmod() is probably not relevant since file modes are not
currently supported.
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
File privileges would also be good to support. But this is
really a small part of a much larger feature. NuttX has no
user IDs, there are no groups, there are no privileges
associated with either. User's don't need credentials.
This is really a system wide issues of which chmod is only
a small part.
User privileges never seemed important to me since NuttX is
intended for deeply embedded environments where there are
not multiple users with varying levels of trust.
truncate - The standard way of setting a fixed file size.
Often used with random access, data base files. There is no
simple way of doing that now (other than just writing data
to the file).
link, unlink, softlink, readlink - For symbolic links. Only
the ROMFS file system currently supports hard and soft links,
so this is not too important.
File locking
Special files - NuttX support special files only in the top-
level pseudo file system. Unix systems support many
different special files via mknod(). This would be
important only if it is an objective of NuttX to become a
true Unix OS. Again only supported by ROMFS.
True inodes - Standard Unix inodes. Currently only supported
by ROMFs.
The primary obstacle to all these is that each would require
changes to all existing file systems. That number is pretty
large. The number of file system implementations that would
need to be reviewed and modified As of this writing this
would include binfs, fat, hostfs, nfs, nxffs, procfs, romfs,
tmpfs, unionfs, plus pseduo-file system support.
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: 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
Status: Open
Priority: Medium-Low
Description: When I enable CONFIG_RAMLOG_CONSOLE, the system does not come up
properly (using configuration stm3240g-eval/nsh2). The problem
may be an assertion that is occurring before we have a console.
Title: UNIFIED DESCRIPTOR REPRESENTATION
Description: There are two separate ranges of descriptors for file and
socket descriptors: if a descriptor is in one range then it is
recognized as a file descriptor; if it is in another range
then it is recognized as a socket descriptor. These separate
descriptor ranges can cause problems, for example, they makes
dup'ing descriptors with dup2() problematic. The two groups
of descriptors are really indices into two separate tables:
On an array of file structures and the other an array of
socket structures. There really should be one array that
is a union of file and socket descriptors. Then socket and
Another example of how the current implementation limits
functionality: I recently started to implement of the FILEMAX
(using pctl() instead sysctl()). My objective was to be able
to control the number of available file descriptors on a task-
by-task basis. The complexity due to the partitioning of
desciptor space in a range for file descriptors and a range
for socket descriptors made this feature nearly impossible to
implement.
Status: Open
Priority: Low
Title: DUPLICATE FAT FILE NAMES
Description: "The NSH and POSIX API interpretations about sensitivity or
insensitivity to upper/lowercase file names seem to be not
consistent in our usage - which can result in creating two
directories with the same name..."
Gregory Nutt
committed
Example using NSH:
nsh> echo "Test1" >/tmp/AtEsT.tXt
nsh> echo "Test2" >/tmp/aTeSt.TxT
nsh> ls /tmp
/tmp:
AtEsT.tXt
aTeSt.TxT
nsh> cat /tmp/aTeSt.TxT
Gregory Nutt
committed
nsh> cat /tmp/AtEsT.tXt
Gregory Nutt
committed
Title: MISSING FILES IN NSH 'LS' OF A DIRECTORY
Description: I have seen cases where (1) long file names are enabled,
but (2) a short file name is created like:
nsh> echo "This is another test" >/mnt/sdcard/another.txt
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
But then on subsequent 'ls' operations, the file does not appear:
nsh> ls -l /mnt/sdcard
I have determined that the problem is because, for some as-
of-yet-unkown reason the short file name is treated as a long
file name. The name then fails the long filename checksum
test and is skipped.
readdir() (and fat_readdir()) is the logic underlying the
failure and the problem appears to be something unique to the
fat_readdir() implementation. Why? Because the file is
visible when you put the SD card on a PC and because this
works fine:
nsh> ls -l /mnt/sdcard/another.txt
The failure does not happen on all short file names. I do
not understand the pattern. But I have not had the opportunity
to dig into this deeply.
Status: Open
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
Priority: Perhaps not a problem??? I have analyzed this problem and
I am not sure what to do about it. I am suspected that a
fat filesystem was used with a version of NuttX that does
not support long file name entries. Here is the failure
scenario:
1) A file with a long file name is created under Windows.
2) Then the file is deleted. I am not sure if Windows or
NuttX deleted the file, but the resulting directory
content is not compatible with NuttX with long file
name support.
The file deletion left the full sequence of long
file name entries intact but apparently delete only
the following short file name entry. I am thinking
that this might have happened because a version of NuttX
with only short file name support was used to delete
the file.
3) When a new file with a short file name was created, it
re-used the short file name entry that was previously
deleted. This makes the new short file name entry
look like a part of the long file name.
4) When comparing the checksum in the long file name
entry with the checksum of the short file name, the
checksum fails and the entire directory sequence is
ignored by readder() logic. This the file does not
appear in the 'ls'.
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
patacongo
committed
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: NxTERM VT100 SUPPORT
Description: If the NxTerm will be used with the Emacs-like command line
Gregory Nutt
committed
editor (CLE), then it will need to support VT100 cursor control
commands.
Status: Open
Priority: Low, the need has not yet arisen.
Description: One of the most awkward things to handle in the NX windowing
system is the re-draw callback. This is difficult because it
requires ad hoc, custom logic to be able to do the redrawing
in most cases.
One solution would be to provide a per-window framebuffer.
All rending would be performed into the per-window framebuffer
and the rended bits would be copied the LCD or framebuffer
device memory on demand when the redraw is required.
This would (a) greatly simplify the graphics interface, (b)
greatly improve redraw performance, and (c) enable a more
generic use of the windowing. The downside would be a large
usage of memory to hold all of the framebuffers, one for each
window.
Status: Open
Priority: Low, of mostly strategic value.
Title: VERTICAL ANTI-ALIASING
Description: Anti-aliasing is implemented along the horizontal raster line
with fractional pixels at the ends of each line. There is no
accounting for fractional pixels in the vertical direction.
As a result lines closer to vertical receive better anti-
aliasing than lines closer to horizontal.
Status: Open
Priority: Low, not a serious issue but worth noting. There is no plan
to change this behavior.
Title: REMOVE SINGLE USER MODE
Description: NX graphics supports two modes: A simple single user mode and
more complex multi-user mode selected with CONFIG_NX_MULTIUSER=y.
In this configuration, an application can start the NX server
with boardctrl(BOARDIOC_NX_START); After that, all graphic
interactions are via a thin layer in libnx/. The OS
interface is only via messages sent and received using POSIX
message queues. So this is good code and respects all of the
POSIX interfacing rules. Hence, it works well in all build
modes (FLAT, PROTECTED, and KERNEL builds).
But without CONFIG_NX_MULTIUSER, the single user applications
violate all of the rules and calls internal NX functions
directly. This includes all calls to internal OSfunctions
with names like, nx_open, up_fbinitialize, board_lcd_*, and
others. This is a violation of interfacing standard in all
cases and can only be made to work in the FLAT build mode.
The single user mode does have some desirable properties: It
is lighter weight and so more suitable for very resource limited
platforms. But I think that in the long run the only reasonable
solution is to eliminate the single user mode and provide only
the multi-user mode with the message queue interface.
Status: Open
Priority: Low-Medium, not a serious issue but worth noting. Single user
mode is a blemish on the OS and not compatible with the RTOS
roadmap. But neither is there any critical necessity to
remove the offending code immediately. Be aware: If you use
the single user mode, it will be yanked out from under your
feet in the not-so-distant future.
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.
Description: The way that apps/ now generates Kmenu files depends on changes added
to apps/tools/mkkconfig.sh. Similar changes need to be made to
apps/tools/mkkconfig.bat to restore the Windows Native build.
UPDATE: The mkkconfig.bat script has been updated and appears to work.
A native build has still not been attempted and there could likely be
issues the carriage returns in Kconfig files. There are also some
issues the interpreters/ficl and bas directories during 'make menuconfig'
that still need to be investigated.
Status: Open
Priority: Low, since I am not aware of anyone using the Windows Native build.
But, of course, very high if you want to use it.
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
Title: CONTROL-C CAN BREAK DEPENDENCIES
Description: If you control C out of a make, then there are things that can go
wrong. For one, you can break the dependencies in this scenario:
- The build in a given directory begins with all of the compilations.
On terminal, this the long phase with CC: on each line. As each
.o file is created, it is timestamped with the current time.
- The dependencies on each .o are such that the C file will be re-
compile if the .o file is OLDER that the corresponding .a archive
file.
- The compilation phase is followed by a single, relatively short
AR: phase that adds each of the file to the .a archive file. As
each file is added to archive, the timestamp of the of archive is
updated to the current time. After the first .o file has been
added, then archive file will have a newly timestamp than any of
the newly compiled .o file.
- If the user aborts with control-C during this AR: phase, then we
are left with: (1) not all of the files have bee added to the
archive, and (2) the archive file has a newer timestamp than any
of the .o file.
So when the make is restarted after a control, the dependencies will
see that the .a archive file has the newer time stamp and those .o
file will never be added to the archive until the directory is cleaned
or some other dependency changes.
Status Open
Priority: Medium-High. It is a rare event that control-C happens at just the
point in time. However, when it does occur the resulting code may
have binary incompatiblies in the code taken from the out-of-sync
archives and cost a lot of debug time before you realize the issue.
A work-around is to do 'make clean' if you ever decide to control-C
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
out of a make. A couple of solutions have been considered:
- Currently, there is a sequence of compilations ins a directory
with messages like CC:, CC:, CC: etc. This is followed by one big
archival AR:
The window in which the control-C problem can occur could be
minimized (but not eliminated) by performing a archival for each
compiliation like CC: AR:, CC: AR:, etc.
- Introduce a spurious dependency that has the correct time stamp.
For example given Make like like (from nuttx/sched/Makefile):
$(BIN): $(OBJS)
$(call ARCHIVE, $@, $(OBJS))
Could be changed like:
.archive: $(OBJS)
$(call ARCHIVE, $@, $(OBJS))
@touch .archive
$(BIN): .archive
.archive would be a totally spurious file that is touched only AFTER
ALL .o files have been archived. Thus is the user control-C's out of
the make during the archival, the timestamp on .archive is not
updated.
The .archive file would have to be removed on 'make clean' and would
also need to appear in .gitignore files.
o Other drivers (drivers/)
^^^^^^^^^^^^^^^^^^^^^^^^
o Linux/Cywgin simulation (arch/sim)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Title: SIMULATOR HAS NO INTERRUPTS (NON-PREMPTIBLE)
Description: The current simulator implementation is has no interrupts and, hence,
is non-preemptible. Also, without simulated interrupt, there can
be no high-fidelity simulated device drivers.
Currently, all timing and serial input is simulated in the IDLE loop:
When nothing is going on in the simulation, the IDLE loop runs and
fakes timer and UART events.
Status: Open
Priority: Low, unless there is a need for developing a higher fidelity simulation
I have been thinking about how to implement simulated interrupts in
the simulation. I think a solution would work like this:
http://www.nuttx.org/doku.php?id=wiki:nxinternal:simulator
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 asynchronous events. This could
probably be fixed if the "timer interrupt" were driver by Linux
signals. NOTE: You would also have to implement up_irq_save() and
up_irq_restore() to block and (conditionally) unblock the signal.
Gregory Nutt
committed
Description: The configuration has basic support SMP testing. The simulation
supports the emulation of multiple CPUs by creating multiple
pthreads, each run a copy of the simulation in the same process
address space.
At present, the SMP simulation is not fully functional: It does
operate on the simulated CPU threads for a few context switches
then fails during a setjmp() operation. I suspect that this is
not an issue with the NuttX SMP logic but more likely some chaos
in the pthread controls. I have seen similar such strange behavior
other times that I have tried to use setjmp/longmp from a signal
handler! Like when I tried to implement simulated interrupts
using signals.
Apparently, if longjmp is invoked from the context of a signal
handler, the result is undefined:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1318.htm
Gregory Nutt
committed
Gregory Nutt
committed
-# CONFIG_EXPERIMENTAL is not set
+CONFIG_EXPERIMENTAL=y
+CONFIG_SPINLOCK=y
+CONFIG_SMP=y
+CONFIG_SMP_NCPUS=2
+CONFIG_SMP_IDLETHREAD_STACKSIZE=2048
You also must enable near-realtime-performance otherwise even long
timeouts will expire before a CPU thread even has a chance to
execute.
-# CONFIG_SIM_WALLTIME is not set
+CONFIG_SIM_WALLTIME=y
Gregory Nutt
committed
And you can enable some additional debug output with:
-# CONFIG_DEBUG_SCHED is not set
+CONFIG_DEBUG_SCHED=y