casaroli opened a new pull request, #19797:
URL: https://github.com/apache/nuttx/pull/19797

   ## Summary
   
   Split from #19772, part 3 of 3, as asked in review.
   
   This is the ESP32-S3 half: a per-process address environment, and `fork()` 
on top of it.
   
   The address environment is built on the SoC's cache MMU, not on anything in 
the Xtensa core. The core contributes only region protection — coarse 512 MB 
regions with no paging — so the per-process mapping comes entirely from the MMU 
that maps external flash and PSRAM into the address space, 64 KB and 32 KB 
pages respectively. This is the reason the code is chip code and not 
architecture code: a non-Espressif LX7 would share none of it.
   
   `up_addrenv_fork()` duplicates an address environment rather than sharing 
it, which is what separates `fork()` from `vfork()`.
   
   The page pool is deliberately left unmapped in the kernel address space. It 
is carved out of the PSRAM the user processes run from, and the external memory 
permissions are indexed by physical address, so a permanent kernel window onto 
the pool would be a window onto every process's memory that no permission 
setting could close. The kernel reaches a pool page through a small scratch 
mapping instead, established for one operation and invalidated afterwards.
   
   Two review points are addressed here.
   
   `ARCH_HAVE_FORK` is now selected by the architecture instead of being 
defaulted from inside its own definition, so the condition sits where a reader 
of `arch/Kconfig` will look for it. It repeats the `ARCH_ADDRENV` dependency, 
because a `select` bypasses `depends on`.
   
   The chip no longer duplicates the page pool settings. `ARCH_PGPOOL_PBASE` 
and `ARCH_PGPOOL_SIZE` were reachable only under `ARCH_PGPOOL_MAPPING`, which 
is why the duplication existed. A physical base and a size describe the pool 
whether or not it is statically mapped — only a virtual base needs the mapping 
— so those two move out of that block and the chip uses them.
   
   ## Impact
   
   The ESP32-S3 gains `CONFIG_BUILD_KERNEL` and `fork()`. Existing flat and 
protected configurations are unaffected.
   
   ## Testing
   
   Board: ESP32-S3-DevKitC. Two modules, an ESP32-S3-WROOM-2 N32R8V with 32 MB 
octal flash and 8 MB octal PSRAM, and an ESP32-S3-WROOM-1 N8R2 with 8 MB quad 
flash and 2 MB embedded PSRAM.
   
   Host: macOS 15 on Apple Silicon, `xtensa-esp32s3-elf-gcc` 12.2.0.
   
   | module | configuration | build mode | flash | result |
   |---|---|---|---|---|
   | WROOM-2 | `esp32s3-devkit:ostest` | flat | octal | `vfork()` passes, 
status 0 |
   | WROOM-2 | `esp32s3-devkit:knsh` | protected | octal | `vfork()` passes, 
status 0 |
   | WROOM-2 | `esp32s3-devkit:kernel_oct` | kernel | octal | `vfork()` and 
`fork()` pass, status 0 |
   | WROOM-1 N8R2 | `esp32s3-devkit:ostest` | flat | DIO | `vfork()` passes |
   | WROOM-1 N8R2 | `esp32s3-devkit:kernel_n8r2` | kernel | DIO | `vfork()` and 
`fork()` pass, status 0 |
   
   ```
   user_main: vfork() test
   vfork_test: Child 6 ran and exited before the parent resumed
   user_main: fork() test
   fork_test: Child running independently (child)
   fork_test: Parent and child had independent memory
   ostest_main: Exiting with status 0
   ```
   
   `tools/checkpatch.sh -c -u -m -g` reports no errors.
   
   depends-on: apache/nuttx/pull/19796
   


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

Reply via email to