Resolution of Issue 619 will require multiple steps, this part of the first step in that resolution: Every call to nxsem_wait_uninterruptible() must handle the return value from nxsem_wait_uninterruptible properly. This commit is only for those files under fs/inode. Utility functions under fs/incode were modified so the changes do extend to other fs/ sub-directories as well.
Squashed commit of the following:
configs/: The few configurations that formerly set CONFIG_NFILE_DESCRIPTORS=0 should not default, rather they should set the number of descriptors to 3.
fs/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
tools/: Tools updates for changes to usage of CONFIG_NFILE_DESCRIPTORS.
syscall/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
libs/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
include/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
drivers/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
Documentation/: Remove all references to CONFIG_NFILE_DESCRIPTORS == 0
binfmt/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
arch/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
net/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
sched/: Remove all conditional logic based on CONFIG_NFILE_DESCRIPTORS == 0
sched/Kconfig: CONFIG_NFILE_DESCRIPTORS may no longer to set to a value less than 3
configs/: Remove all settings for CONFIG_NFILE_DESCRIPTORS < 3
I see the following behaviour on NuttX 7.26, where I have SD card mounted on /flash and a directory called "frm" on it:
opendir("/flash") returns (DIR *) 0x1000c580
opendir("/flash/") returns (DIR *) 0x1000c5d0
opendir("/flash/frm") returns (DIR *) 0x1000c620
opendir("/flash/frm/") returns (DIR *) 0x0
From POSIX specs for opendir(): "A pathname ... that ends with one or more trailing slashes shall be resolved as if a single dot character ( '.' ) were appended to the pathname."
So for mount points, opendir() works correctly, but for FAT32 filesystem it fails to open directory if the path has a trailing slash. I'm not quite sure how to cleanly fix this. Stripping the trailing slash in opendir() would require allocating a separate buffer, while fixing it in the FAT32 code seems somewhat complex due to the short/long filename logic.
It is not a big issue for me, I'm just going to fix it on the application side. But still a small portability and standards compliance issue.
NOTE: You would not see this problem if you call opendir() indirectly in NSH (like 'ls -R /') because NSH contains logic to remove trailing '/' characters from paths.
Xiang Xiao