casaroli opened a new pull request, #21323:
URL: https://github.com/apache/nuttx/pull/21323
## Summary
The pseudo file system had no directory of the shared memory objects
(`CONFIG_FS_SHMFS_VFS_PATH`) until the first `shm_open()` created one, and no
`/dev/pts` until the first pseudo-terminal was opened. Programs expect both
directories from boot, as on other systems: a program that lists them, or
checks that it can create a file there, fails. User code cannot always create
them: with a file system mounted at `/`, `mkdir("/dev/shm")` creates the
directory in that file system, not in the pseudo file system.
- New `register_pseudodir(path, mode)` (`fs/driver/fs_registerpseudodir.c`,
declared in `include/nuttx/fs/fs.h` next to `register_driver()`): it creates an
empty directory in the pseudo file system, for a driver or a file system that
creates its nodes below it later.
- `fs_initialize()` calls the new `shmfs_initialize()`, which creates
`CONFIG_FS_SHMFS_VFS_PATH` with mode 1777.
- `ptmx_register()` creates `/dev/pts` with mode 0755 before it registers
`/dev/ptmx`.
The second commit documents `register_pseudodir()`
(`Documentation/os/filesystem/special_files_dev_num.rst`) and the directory of
the shared memory objects (`shmfs.rst`).
## Impact
Only with `CONFIG_FS_SHMFS` or `CONFIG_PSEUDOTERM_SUSV1`: the two
directories exist from boot, in every build mode. Without these options nothing
changes. `register_pseudodir()` is a new kernel-internal function; no existing
interface changes.
A mount at the directory or at a parent of it (for example at `/var` with
the default `/var/shm`) still works: `mount()` takes an existing pseudo
directory as its mount point. With `CONFIG_DISABLE_PSEUDOFS_OPERATIONS`,
`mount()` does not take an existing pseudo directory (master behaves the same
after the first `shm_open()`); no defconfig enables `CONFIG_FS_SHMFS` with it.
## Testing
Base: master 5c441693fa8. Test program `devdirs.c` (QEMU with HVF), with
`CONFIG_FS_SHMFS`, `CONFIG_PSEUDOTERM` and `CONFIG_PSEUDOTERM_SUSV1`:
`qemu-armv8a:knsh` (kernel build, `CONFIG_FS_SHMFS_VFS_PATH="/dev/shm"`), the
same with `CONFIG_FS_PERMISSION`, and `qemu-armv8a:nsh` (flat build, the
default `/var/shm`). The results are the same in the three configurations:
| Check | master | this PR |
|---|---|---|
| the shm directory is a directory and `opendir()` works before the first
`shm_open()` | FAIL | PASS |
| `/dev/pts` is a directory and `opendir()` works before the first
pseudo-terminal | FAIL | PASS |
| the object is listed after `shm_open()`; after `shm_unlink()` it is gone
and the directory stays | PASS | PASS |
| the slave is listed in `/dev/pts` after `openpty()`; after `close()` of
both ends it is gone and `/dev/pts` stays | PASS | PASS |
With `CONFIG_FS_PERMISSION`, `stat()` gives mode 1777 for `/dev/shm` and
0755 for `/dev/pts`, and `shm_open()` works for uid 1000. `openpty()` fails for
uid 1000 with `EACCES` on master and with this PR, because `/dev/ptmx` has mode
0600.
ostest exits with status 0 on `qemu-armv8a:knsh` (both configurations), and
`qemu-armv8a:nsh` (with and without the test), on master and with this PR.
Build, each OK, with no warnings in the changed files: with
`CONFIG_FS_SHMFS` and `CONFIG_PSEUDOTERM_SUSV1`: `rv-virt:nsh64` (flat, rv64),
`rv-virt:pnsh64` (protected, rv64), `rv-virt:knsh64` (kernel, rv64, with a
mapping area, which `CONFIG_FS_SHMFS` needs in a kernel build),
`mps2-an500:knsh` (protected, Cortex-M7), `qemu-armv8a:nsh` (flat, arm64) with
`CONFIG_FS_NOTIFY` and `CONFIG_PSEUDOFS_ATTRIBUTES`, and with
`CONFIG_DISABLE_PSEUDOFS_OPERATIONS`; without the options: `rv-virt:knsh64`,
`qemu-armv8a:nsh`; `stm32f103-minimum:adb` (flat, Cortex-M3, has
`CONFIG_PSEUDOTERM_SUSV1` and `CONFIG_DISABLE_PSEUDOFS_OPERATIONS`: 68 bytes
more than master); CMake: `qemu-armv8a:nsh` with the options and
`CONFIG_FS_NOTIFY`.
`tools/checkpatch.sh -c -u -m -g` passes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
