[RFC] Situation with Zephyr POSIX subsystem and ARCH_POSIX (targets running on the underlying POSIX OS)

[pfalcon]

Subj is a cause of continued cases of failures and frustrating workarounds in Zephyr. Something needs to be done about it. Two obvious choices are:

1. Say that POSIX subsys of Zephyr is not compatible with ARCH_POSIX. This is very obvious and right solution.
2. Call for all-hands work from the maintainers of both parts, work hard on them, and then it's still unclear how far we'll get with that.

[pfalcon]

cc: @nashif

[aescolar]

@pfalcon : Having the same POSIX APIs both above and below Zephyr does certainly require some cheating to make it work.
But I hope it does not lead to too much frustration overall.
We need to be aware about how that is made to work (how those cheats work) and ensure we don't break them.
I think giving up on supporting the POSIX API on top of the POSIX arch is a bit too dramatic at this point.

Could you be a bit more specific about what are those continued failures and frustrations? (so we can address them)
If the problem is understanding how it is made to work today, we can fix that.
Is there any current broken functionality in this regard? (that warrants the bug Label?)

[pfalcon]

So, the problem is that there's too much magic in each of the subsystems above. I'm working on de-magicize POSIX API subsystem, but I get blocked by native_posix failures on each step.

Here's an example case transcript:

1. [WIP][DNM] lib: posix: Elaborate for wider yet more selective POSIX coverage #12984 fails with:

/home/buildslave/src/github.com/zephyrproject-rtos/zephyr/arch/posix/include/posix_cheats.h:36:32: error: unknown type name ‘zap_pthread_attr_t’
 #define pthread_attr_t         zap_pthread_attr_t

2. Looking at that file, it says:

/* For the include/posix/pthreads.h provided with Zephyr,
 * in case somebody would use it, we rename all symbols here adding
 * some prefix, and we ensure this header is included
 */

3. we rename all symbols here - Ok, rename to what? Grepping thru the codebase, I don't fine definition of "zap_pthread_attr_t". Is "zap" here a pun? I'd say it's rather unclear then, should be named something like "dontuse_pthread_attr_t". In either case, should be properly explained in the comment.
4. and we ensure this header is included - Ok, how? Grepping thru the codebase, I see that the file is never included. Grepping more, I see that it's references from CMake*.txt. Again, should be better documented.
5. See no docs in comments, I do git log posix_cheats.h to see if commit messages had more detailed information, and instead find tests/posix/fs/ segfaults randomly in POSIX arch #13011, which both not cc'ed to make (even though it fixes the commit I made), and causes random segfaults. All that only proves the points made about.

So, the point that there should be much better synchronization between CONFIG_POSIX_API and CONFIG_ARCH_POSIX developers, which first requires cleaning up and documenting better both. There're (as usual) currently no resources for that, so better for now would be just separate one from another until it's more stabilized and we can work on a specific task on integrating both together (to the extent possible, which is so far unknown and requires separate research task).

So, I'll be looking into blacklisting native_posix for tests/posix/ in the meantime, but comments are welcome.

[pfalcon]

But I hope it does not lead to too much frustration overall.

Well, It does, for quite some time now. Any change to the POSIX subsys leads to breakage of CI re: native_posix.

I think giving up on supporting the POSIX API on top of the POSIX arch is a bit too dramatic at this point.

It's not like "giving up", it's more like accepting that it's a separate task to integrate both, which so far severely interferes with the development of POSIX subsys itself. After last working streak on it in September or so, I tried to stay away from it. Now I need to work on it again, and the same breakage-on-each-step story repeats.

[aescolar]

Ok, you raise several points which require separate answers:

• Regarding not having CC'ed you: Actually that was a silly mistake from my side. When fixing it, I had incorrectly thought it was a change by Ulf, so I had added him as reviewer instead of you.
• The symbols which require renaming are those the linker may get confused about. And those are the functions we (may) use both from the POSIX arch and the POSIX API.
  The types do not really need to be renamed. You should be able to just remove those #defines from the posix_cheats.h header. (Having the types also renamed may help somebody inspect the compiler output to know what he is doing).
• ZAP: Initially it came from "Zephyr APPlication", (before the POSIX API, only main() needed to be renamed. "zap_" is just as good as any unlikely random string, which hopefully does not cause collisions with other symbol names.
• You cannot find anywhere in the codebase any other symbol matching zap_* for that reason. The idea is that, wherever you include posix_cheats.h (which should be everywhere automatically, except where it is on purpose excluded (POSIX arch private files), your function definition or function call (say pthread_attr_init( ) ) gets renamed by the C pre-processor (to zap_pthread_attr_init( )), so it does not collide with the host one on link time.
• Apart from this, you need to be careful to include the Zephyr POSIX API headers and not the host ones.when compiling for native_posix. Say by including "posix/banana.h" instead of <banana.h>.
• That comment at the beginning of posix_cheats needs to be updated. At the time that was written only the pthreads.h one had been added to Zephyr. Now it applies for all "POSIX compatible APIs in Zephyr"
• Yes, we probably should better document this in the posix_cheats.h header itself (at least).