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