Mirrors_Framework/nuttx
1
0
Fork 0
mirror of https://github.com/apache/nuttx.git synced 2026-05-31 05:55:46 +08:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Update TODO list

Browse Source
This commit is contained in:
Gregory Nutt
2015-01-31 12:29:02 -06:00
parent 3e072ae23e
commit 85dc0f5cd7
1 changed files with 14 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TODO
+14 -12
View File
@@ -927,22 +927,24 @@ o Network (net/, drivers/net)
Description: FIFOs are used as the IPC underlying local Unix domain sockets. Description: FIFOs are used as the IPC underlying local Unix domain sockets.
In NuttX, FIFOs are implemented as device drivers (not as In NuttX, FIFOs are implemented as device drivers (not as
special files). The FIFO device driver is instantiated when special files). The FIFO device driver is instantiated when
the Unix domain socket communications begin. But there is no the Unix domain socket communications begin and will
mechanism in place now to delete the FIFO device driver automatically be released when (1) the driver is unlinked and
instance when the Unix domain socket is no longer used. The (2) all open references to the driver have been closed. But
underlying buffer is deleted, but the driver instance itself there is no mechanism in place now to unline the FIFO when
remains. unlink() could be used to get rid of the driver the Unix domain socket is no longer used. The primary issue
name in the pseudo-filesystem, making the drvier inaccessible. is timing.. the FIFO should persist until it is no longer
But it will not free the driver. A new interface, say rmfifo(), needed. Perhaps there should be a delayed call to unlink()
would be required to do that. (using a watchdog or the work queue). If the driver is re-
opened, the delayed unlink could be canceled? Needs more
thought.
Status: Open Status: Open
Priority: Low for now because I don't have a situation where this is a 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 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 it is not a issue; in fact it is more efficient if the FIFO
devices persiste. But this would be a serious problem if, devices persist. But this would be a serious problem if,
for example, you create new Unix domain paths dynaically. In for example, you create new Unix domain paths dynamically.
that case you would effectly have a memory leak and the number In that case you would effectively have a memory leak and the
of FIFO instances grow. number of FIFO instances grow.
o USB (drivers/usbdev, drivers/usbhost) o USB (drivers/usbdev, drivers/usbhost)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^