On 7.4.2022 8.18, Xiang Xiao wrote:
On Wed, Apr 6, 2022 at 8:20 PM Jukka Laitinen <jukka.laiti...@iki.fi> wrote:
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.
This patch associate struct file with strucct fs_rammap_s, may help you:
https://github.com/apache/incubator-nuttx/pull/5997
Hm, not really. the rammaps look like a hackish thing which only works
for flat&protected build (it is a single global list of "mappings").
I'd rather add a list of named mappings to task group. In mmap/munmap
one can then add&remove mappings from the list. This would be then later
extendable to also current shm&rammaps if feasible. This would be
inspired by what linux does (list of vm_structs inside mm_struct); I
don't remember the details how it works in linux though (it's been +10
years since I worked on linux internals). It is also maybe better not to
look into details at this point when going to implement something under
Apache... Anyhow, this feature could then be behind some CONFIG_ flag,
which could be selected by anyone needing it, regardless of the build
mode. But it shouldn't be much added memory consumption.
How would this sound?
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
