Sarthak-Pandey commented on issue #14260: URL: https://github.com/apache/nuttx/issues/14260#issuecomment-6229881702
Hi @xiaoxiang781216 , Thank you for the pointer to PR #20565! That was a huge step forward in cleaning up `<stdio.h>`. I am looking to continue this work for **Flat and Protected modes** so that third-party libraries (like `libarchive`, which collide on internal functions like `file_read`) can compile cleanly across all MCU targets. Before opening a PR, I wanted to get your thoughts on the best approach forward: ### Approach 1: Full Decoupling (Mirroring #20565 across Flat/Protected) * Completely remove `#include <nuttx/fs/fs.h>` from `<stdio.h>` for all builds. * Audit and patch all files across `arch/`, `drivers/`, `fs/`, and `net/` that relied on `<stdio.h>` to transitively pull `fs.h` (preliminary audit shows ~75 files). * *Advantage:* 100% clean POSIX `<stdio.h>` across the entire repository with zero leaked kernel types or function names. * *Trade-off:* Touches ~75 files in `nuttx` plus potential companion updates in `nuttx-apps`. ### Approach 2: Two-Step Phased PRs * **PR 1:** Add the explicit `#include <nuttx/fs/fs.h>` to the affected drivers and architecture files *first* (safe, non-breaking). * **PR 2:** Once PR 1 and any `nuttx-apps` dependencies are merged, remove `fs.h` from `<stdio.h>`. * *Advantage:* Easier to review, prevents breaking CI, and ensures clean git bisectability. ### Approach 3: Symbol Guarding in `fs.h` * Keep `fs.h` in `<stdio.h>` for Flat mode for now, but guard conflicting internal function prototypes (e.g., `file_read`, `file_seek`, `file_ioctl`) behind internal guards so user-space and third-party libraries don't see them. * *Trade-off:* Does not solve collisions with `struct file` or `struct inode`, only function names. Do you prefer we go with **Approach 1 (or 2)** to permanently solve the indirect dependency issue, or is there another preferred direction for Flat mode? Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
