diff options
author | Gregory Nutt <gnutt@nuttx.org> | 2015-03-14 16:48:45 -0600 |
---|---|---|
committer | Gregory Nutt <gnutt@nuttx.org> | 2015-03-14 16:48:45 -0600 |
commit | e3fa0599d86506b6b79723ddffeca038440e40a6 (patch) | |
tree | 8929732aae71de32ef20b3fc60a6fa548b768051 /nuttx/TODO | |
parent | 42132b61b6b0add6342560394d578cf2c727b29c (diff) | |
download | px4-nuttx-e3fa0599d86506b6b79723ddffeca038440e40a6.tar.gz px4-nuttx-e3fa0599d86506b6b79723ddffeca038440e40a6.tar.bz2 px4-nuttx-e3fa0599d86506b6b79723ddffeca038440e40a6.zip |
Add umount2(). umount() is now a macro that just calls umount2() with flags = 0.
Diffstat (limited to 'nuttx/TODO')
-rw-r--r-- | nuttx/TODO | 55 |
1 files changed, 53 insertions, 2 deletions
diff --git a/nuttx/TODO b/nuttx/TODO index a2b3df9f0..c526a7d15 100644 --- a/nuttx/TODO +++ b/nuttx/TODO @@ -1,4 +1,4 @@ -NuttX TODO List (Last updated March 10, 2015) +NuttX TODO List (Last updated March 14, 2015) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This file summarizes known NuttX bugs, limitations, inconsistencies with @@ -18,7 +18,7 @@ nuttx/ (12) Network (net/, drivers/net) (4) USB (drivers/usbdev, drivers/usbhost) (11) Libraries (libc/, libm/) - (11) File system/Generic drivers (fs/, drivers/) + (12) File system/Generic drivers (fs/, drivers/) (9) Graphics subystem (graphics/) (1) Pascal add-on (pcode/) (1) Documentation (Documentation/) @@ -1303,6 +1303,57 @@ o File system / Generic drivers (fs/, drivers/) Status: Open Priority: Medium + Title: UNMOUNT WITH OPEN FILES + Description: What is the policy for umounting files that have open file + references? Currently, umount() does the unmount + unconditionally and this has been noted to cause crashes in + some subsequent FAT file system operations. umount() is not + a standard OS interface and so have no specification. Here + are some possible behaviors or unmount() with open files: + + 1. Refuse to unmount() the file system if there are open + references to files on the file system (i.e., the file + system unbind() method returns a failure). + 2. The file system knows that it has open references and so + does not unbind() immediately, but defers until the last + file is closed. + 3. The file system performs the unbind() immediately, but + returns an error for an any subsequent operations on the + file system using one of the stale file handles. + 4. In your application, do not un-mount until you have closed + all references to files or directories in the file system. + This would probably be a good practice anyway. + + I lieu of any real specifications, I often just do what Linux + does. Here is now Linux does things: + http://man7.org/linux/man-pages/man2/umount.2.html . + Linux has have a umount2() that takes flags that control these + behaviors. They have a couple of other options as well. + + It is not explicitly stated in the manpage, but it looks like + the Linux umount() does the first option: It should return + EBUSY meaning that the "target could not be unmounted because + it is busy." That one is pretty easy to implement within the + filesystem unbind() method. + + I now think for an embedded system with mostly removable + storage devices, the option 3 is probably the most usable. For + example, NuttX has a little automounter at nuttx/fs/mount/fs_automount.c + That will automatically mount and unmount SD cards as they are + inserted or removed. I think that is a desire-able feature on + an embedded device. And I think it demands option 3 where the + umount occurs immediately, but then subsequent operations on + the volume fail. + + The true lazy umount could also cause issues if the file is + never closed. Of course if the media is gone, I would hope + that the file access also fail in that case. But what if the + media is inserted and removed many times. Seems like the lazy + unmount could cause some problems and won't really buy you + anything anyway (because the file I/O will fail anyway). + Status: Open + Priority: Medium-High + o Graphics subsystem (graphics/) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |