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 -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 > >> > >> > >> > >> > >> > >> >
