On Thu, Apr 7, 2022 at 1:51 PM Jukka Laitinen <jukka.laiti...@iki.fi> wrote:
> > 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"). > Yes, the global list assumes that we use the unified address space(the address space of the user process isn't overlapped with each other). Only flat and protected mode satisfy the assumption. > 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? The change could simplify move g_rammaps to task_group_s to fix the address space overlap in kernel mode. > >> > >> 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 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >
