pussuw commented on PR #12041: URL: https://github.com/apache/nuttx/pull/12041#issuecomment-2036258592
> @pussuw thanks for the explanations. > > did you mean that we > > * reuse the `vm_alloc_region()` and `vm_alloc_release()` for virtual address allocation. > > * reuse the `up_shmat()` and `up_shmdt()` for mapping/unmapping. > > * don't use anything in `mm/shm` or `fs/shm`. > > Yes, this should work. It is not clear to me what you are trying to do in user space, but I think you will use mmap() to map some device ? > The memory mapping virtual address zone is defined by `ARCH_SHM_NPAGES` and `ARCH_SHM_MAXREGIONS` etc, as long as this zone is big enough, we can use it for both shared memory and device mappings. We also don't need worry about affecting the shared memory use cases as the device mappings don't occupy any shmid. Is this correct? > Yes, especially you do not need to worry about `SHM_MAXREGIONS`, that is only used by SysV shared memory, maybe you can familiarize yourself with the implementation of that, I'm not too familiar with the details. I obviously encountered it when shared memory support was implemented for risc-v. `ARCH_SHM_NPAGES` defines the amount of _virtual memory_ that is allocated for shared memory objects (really, for ANY objects mapped to user virtual memory). > As `vm_alloc_region()` has limitations now and can't do 640x480x4=1228800 frame buffer yet, maybe we can use static virtual address plan for devices? If so, should the static address space be separated from the above space for dynamic mapping? What are the limitations ? I don't understand why this is an issue ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
