For direct user level access, one option is to move tg_envp to TLS / task_info_s. This way the user could access the memory without boring a hole into the kernel.
In KERNEL mode this issue is very simple; every process has its own instance of environ** anyway so there is no need to use TLS or anything. However, in FLAT mode having a per-process instance of environ** is going to be more difficult. You could -in theory- make a reference to the TLS area and use it like that. This reference would have to be updated on every context switch. Whether or not this is even possible to implement in a multicore (SMP) system is beyond me, the reference would need to be duplicated on every CPU and the user would need to be able to query which CPU it is running on. You could combine Takashi's idea with TLS to achieve a "good enough" solution. -Ville ________________________________ From: Gregory Nutt <spudan...@gmail.com> Sent: Tuesday, November 5, 2024 2:39 PM To: dev@nuttx.apache.org <dev@nuttx.apache.org> Subject: Re: POSIX environ variable On 11/5/2024 3:43 AM, Takashi Yamamoto wrote: > i guess it's possible to implement it similarly to what we do for errno. > > eg. > # define environ (*get_environ_ptr_ptr()) > > although it still isn't quite posix compatible, it might be good > enough for many applications. > d18be28c82a2a6d82115c8af19d/shell/ash.c#L10574 There would be a complexity in this: The environ is shared by all threads in a task group. Hence, the environ lies in the protected, kernel task group structure. That structure is not accessible to user code in PROTECTED or KERNEL build modes. So in order to do what you want, you would need to (1) redesign how common data is stored so that the environ is accessible from user space or (2) marshal the environ to other accessible memory when it is requested. Neither are simple and the latter would have synchronization issues. I think there is an open issue about the POSIX compatibility of the environment.
