>I think this is already done for a few group common things. This is what task_info_s in TLS does, it is the "process common information" field. So putting env there would work for the whole process.
The name "TLS" here is a bit confusing, obviously the env data is shared by the process and all its threads. -Ville ________________________________ From: Gregory Nutt <spudan...@gmail.com> Sent: Tuesday, November 5, 2024 3:35 PM To: dev@nuttx.apache.org <dev@nuttx.apache.org> Subject: Re: POSIX environ variable On 11/5/2024 6:57 AM, Ville Juven wrote: > 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. The same environ is used by all threads in a task group/process. If one thread changes the environment, it effects all threads in group/process It could be possible to put the environment in the TLS of the main thread and other could the access indirectly through their TLS references. > 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. Yep. Lots of things are simpler in true kernel mode. Just like the designers of Unix intended! NuttX is more complex and requires some trade-offs. > 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. I think this is already done for a few group common things. But I don't remember. I haven't been that active for awhile (I got too old! 74 in three days).
