The custom handler isn't enough here, because the real problem is we need
the global variables per task/process.
As Greg suggests, we need something like TLS but per task/process not per
thread(e.g. task_getspecific/task_setspecific).
Once the mechanism is done, getopt can be converted to confirm the standard
trivally.
The mechanism there to emulate per process global variables. It is the
task group. Data added to the task group structure is per
task/process. Examples are file descriptors and signal handlers which
must follow that scoping
The transparent/standard solution is switched to the ELF binary(note: it
doesn't depend on KERNEL mode), and then loses the XIP benefit(huge memory
penalty). But, it's doable to XIP again by combining ELF loader and ROMFS.
ELF can never be XIP from ROMFS because it requires relocations inside
of the ELF image to link to the base system.
In Linux, ELF is separated into a text region that holds the shared code
and a RAM region (the Global Offset Table "GOT") that is positioned
right after the text region using the MMU. The GOT is not useful in the
NuttX model because we cannot force the GOT to a known position with the
MMU. So the GOT is not included in the link and relocations must be
performed directly into the ELF text region
NxFLAT will run XIP from ROMFS because it does all relocations in a
"thunk" layer outside of the text region. But NxFLAT has some other
limitations with regard to points.
When using globals, best practice is to make it really clear that the
variables are global. Many programmers do this by prefixing global
variable names with g_*.
This prefix is required by the coding standard.
Yes, my concern is about functions such as getopt(). If you just follow the
description of the API and use it as normal you reach this pitfall. I was
looking
for some approach to avoid this as much as possible. For getopt() I see
there's
even no standard getopt_r(), so we would have to provide our own, which
may not
be a bad idea.
Still, this issue will probably present in many other places.
Seldom people will call getopt_r in Linux, because the different process
gets the new and clean copy, but it is crucial for NuttX to work correctly.
Yes, getopt_r isn't standardized by committee, but it follows the
convention used by other similar functions(e.g. strtok_r) and implemented
by glibc.
getopt_r is unnecessary in Linux since it naturally has per process
global variables. Using getopt_r would serve no purpose in a true Unix
environment and, hence, it not included in any standard.
