Implement FileX support for ThreadX modules

[fdesbiens]

Background

common_modules has carried hook points for FileX since the original Express Logic design, but no implementation has ever existed. Defining TXM_MODULE_ENABLE_FILEX today fails immediately at #include "txm_module_filex.h" (common_modules/inc/txm_module.h:58), because that header exists in no Eclipse ThreadX repository. The same is true for NetX, NetX Duo, USBX and GUIX; this issue covers FileX only, and the resulting pattern should serve as the template for the others.

This issue supersedes #237.

Existing hook points in the kernel

The module manager already reserves and routes everything FileX needs. Nothing in this list needs to change.

Location	Role
common_modules/inc/txm_module.h:333-334	Reserves API IDs TXM_FILEX_API_ID_START (1000) through TXM_FILEX_API_ID_END (1999)
common_modules/module_manager/src/txm_module_manager_kernel_dispatch.c:907	Routes those IDs to _txm_module_manager_filex_dispatch()
common_modules/module_manager/src/txm_module_manager_object_pointer_get_extended.c:449	Routes TXM_FILEX_OBJECTS_START..END to _txm_module_manager_filex_object_pointer_get()
common_modules/module_manager/src/txm_module_manager_stop.c:42,265	Calls _txm_module_manager_filex_stop() during module teardown
common_modules/module_lib/src/txm_module_callback_request_thread_entry.c:200	Dispatches TXM_FILEX_CALLBACKS_START..END to _txm_module_filex_callback_request()

Proposed design

The implementation belongs in the eclipse-threadx/filex repository, not in threadx, so that FileX owns its own module shim and the kernel keeps no knowledge of FileX internals. Proposed layout:

• filex/common_modules/inc/txm_module_filex.h — the missing header: FileX API ID enumeration within 1000-1999, object type and callback type ranges, and the #define fx_* _txm_module_fx_* remapping that makes module source compile unchanged against the shim.
• filex/common_modules/module_lib/src/ — one small file per remapped FileX service, each marshalling its arguments into a _txm_module_system_call4() with the matching API ID. This mirrors the existing common_modules/module_lib/src/txm_module_thread_create.c style exactly.
• filex/common_modules/module_manager/src/txm_module_manager_filex_dispatch.c — the resident-side switch on the API ID that validates every pointer argument and then calls the real FileX service.
• filex/common_modules/module_manager/src/txm_module_manager_filex_object_pointer_get.c, ..._filex_stop.c, and the callback request path.

Security requirements

These are the reason this is not a mechanical wrapping exercise, and they must be settled before any code is written.

1. Every pointer crossing the boundary — FX_MEDIA *, FX_FILE *, name strings, and read/write buffers — must be validated with txm_module_manager_object_pointer_get() or the memory-range checks used by the existing dispatch functions. A module must never be able to hand the resident area a forged FX_MEDIA pointer.
2. Read and write buffers must be proven to lie entirely inside the calling module's data area, with the length checked for overflow, before FileX touches them.
3. Objects such as FX_FILE should be referenced by handle rather than by address from the module side, so that the module never holds a resident pointer.
4. _txm_module_manager_filex_stop() must close every file and unmount every medium the module opened, so that stopping or unloading a module cannot leave FileX with dangling state.
5. The media driver stays entirely resident. Modules do not supply drivers.

Open questions

• Which subset of the FileX API is in scope for a first implementation? I suggest the file and directory services plus fx_media_open/fx_media_close/fx_media_flush, and explicitly excluding fault-tolerant and multi-threaded media sharing until the basics are proven.
• Should the shim be built by the FileX CMake at all times, or only when TXM_MODULE_ENABLE_FILEX is defined?
• Validation requires a Cortex-M target with MPU support running a module that performs real file I/O; we need to agree on a reference board before this can be called done.

Acceptance criteria

• A module built against the shim compiles and runs with TXM_MODULE_ENABLE_FILEX defined, with memory protection enabled.
• Every argument-validation path has a negative test proving a malicious module is rejected rather than crashing the resident area.
• Stopping the module releases all FileX resources.
• The pattern is documented well enough to be reused for NetX Duo, USBX and GUIX.