Hi!
Just started crafting the posix shm driver, with the following:
- Started with "driver" approach (i.e. not mountable fs), similar to
mqueue.
- Added shm_open and shm_unlink to syscalls (similarly as mq_open).
shm_unlink would *maybe* also work directly through vfs, but at least
shm_open needs to be there; it is not possible to create a file via
basic "open" (vfs/fs_open) for a "driver".
- Added an ioctl for ftruncate, since file_operations don't have truncate
Now I realized that there is a problem with munmap; there is no clear
way to translate address+len into a mapped file, so it is not really
possible to do e.g. an ioctl to the shmfs. I wonder what would be a good
way to solve this? I could:
- leave munmap unimplemented for now (then it is not possible to really
free memory once allocated by a shared memory object).
- implement some sort of support for named mmappings (e.g. at mmap
reserve some extra space in front of every mapping for mmap info, and
use this in fs/mm/fs_munmap to find the proper file/driver)
- always send an ioctl for shmfs driver, and keep the info of mapped
areas there (quite ugly).
- something else, ideas?
Suggestions? Maybe I missed something, but I didn't see an obvious way
to do munmap.
-Jukka
On 5.4.2022 14.04, Xiang Xiao wrote:
On Tue, Apr 5, 2022 at 5:08 PM Jukka Laitinen <jukka.laiti...@iki.fi> wrote:
Hi!
I would like to do the posix shm interface for NuttX (shm_open,
shm_unlink etc.); with the following properties
- Would work in all memory protection modes (flat, protected and kernel).
- In flat it would just "malloc" the memory and share the pointer
w. mmap
- In protected it would per CONFIG_ flag either do malloc from user
heap, or alternatively from a dedicated shm heap
- In kernel build it would do the proper allocation by gran
allocator & mmap, basically wrapping the existing shm interface
My use case is applications, which can communicate over shm, would work
the same for linux and nuttx, and would be usable in nuttx in all the
build modes.
Now, I started looking into fs/shm and made the observation
(fs/Makefile, etc) that initially the intention has been that the shm is
not a mountable filesystem, but rather similar to mqueue, socket and
semaphore. This seems to bring the problem that only mountable
filesystems support "truncate", which is used in posix shm to set the
size of the shared object.
Another thing which I was wondering is, that we could maybe mimic linux,
which uses tmpfs for shared memory. There I noticed, that tmpfs doesn't
support kernel build. It doesn't use gran allocator to allocate on page
boundaries, nor proper mmap). Tmpfs also feels a bit complex for the
purpose. I'd maybe rather target for a minimized implementation.
So, I am basically asking opinions on how this would be best :)
1. Does the above make any sense, would others be interested in posix shm ?
Yes, it's very useful.
2. Is it feasible if I do shm as an own "mountable" filesystem (to
support truncate), or is there something I missed?
One possible solution is add FIOC_TRUNCATE, so the char driver could
implement the truncation in ioctl callback.
3. The support for flat and protected modes can be built into fs layer,
or additionally added to the existing shm interface. Which way feels
arhitecturally better for others? I would initially default to putting
it directly into shm fs, to avoid modifying the existing shm if.
It's better to follow mqueue structure:
1. All functionality except naming is located at mm/shm
2. The file system integration is located at fs/shm
Br,
Jukka
