Description
FileX isn't supposed have a hard dependency on ThreadX, yet it does, and it even depends on its internals, and it probably causes real bugs.
Example:
https://github.com/eclipse-threadx/filex/blob/master/common/src/fx_directory_local_path_set.c#L147
FileX uses _tx_thread_current_ptr, which is ThreadX-specific, and internal to ThreadX. It's so internal that ThreadX doesn't even expose it in its API headers, so FileX just defines it itself (what an excellent WTF):
https://github.com/eclipse-threadx/filex/blob/master/common/inc/fx_api.h#L225
I can't believe that ThreadX itself contains FileX-specific code to support this:
https://github.com/eclipse-threadx/threadx/blob/master/common/inc/tx_api.h#L552
As you can see, just accessing that _tx_thread_current_ptr global variable is probably not correct on the ThreadX SMP kernel:
https://github.com/eclipse-threadx/threadx/blob/master/common_smp/inc/tx_api.h#L1169
https://github.com/eclipse-threadx/threadx/blob/master/common_smp/src/tx_thread_identify.c#L96
How could it, there's probably no TLS support at all. This leads me to believe that using API like fx_directory_local_path_set() leads to undefined behavior (for managers: BIG $$$ LOSS) if used on ThreadX SMP builds. I can't believe I'm finding such nonsense and beginner level mistakes in a proven RTOS that prides itself on having received safety certification by TÜV. (Maybe FileX isn't meant to live up to the standards ThreadX adheres to, but there's still FileX-specific code in ThreadX...)
You can disable this feature with FX_NO_LOCAL_PATH, but this leads to further inconveniences. The local path feature has some justification (it's like a per-thread chdir()), but it should not depend on ThreadX internals. It shouldn't require ThreadX either. But what I would actually expect is a sane API like POSIX opendir().