Thanks for the comments, I’ve taken some time away from this RFC to focus on other things, but I am coming back. I’ve taken some time to rethink my decision with the PR, and how it will affect things down the line.
We do require full FILE* instances as per our customer requirements, and as @mysterymath said, I think a lot of it could be shared with the generic implementation. I think there were plans (cc: @michaelrj-google) to redo the FILE interface anyways. I would disagree with the idea to let users just implement whatever functions they require, as this ends up rendering most of the libcxx I/O functions useless.
Personally I have seen 2 main uses for baremetal, semihosting and UART. As long as we define the hooks for write, read, seek?, flush? and flags, I think anything should work.
In the future we could get a mini-stdio library similar to what a lot of embedded systems currently have or an option to disable full FILE* support.
Proposal 1: Tear down the stdio/baremetal folder
We can leave in some functions like remove() but this proposal would get rid of stdio/baremetal/printf.cpp and all other functions that the generic function would implement.
To do this, we take the Linux implementation and adapt it to the baremetal implementation. In src/__support/File we can use a CookieFile instead of defining a unique class for baremetal. Then, we can hook up the embedding API to these cookies.
From a user’s POV:
- they will still have to define the embedding API, similar to what we have in our semihosting library downstream (arm-toolchain/arm-software/embedded/llvmlibc-support/semihost/semihost.cpp at 58c612f985b98748652c819be0357dba95c0b71c · arm/arm-toolchain · GitHub) such as
__llvm_libc_stdio_readand__llvm_libc_stdio_write. - they will NOT have to define
stdout/stderr/stdin. This will be defined insrc/__support/File/baremetal/std*.cpp. This has the added benefit of making hermetic tests work downstream ([libc] Tracking progress for adding hermetic testing on baremetal · Issue #145349 · llvm/llvm-project · GitHub) as I cannot usefopencookie()in the semihosting library when running hermetic tests downstream due to it calling a libc function (there is a link errror). - this has implications in terms of code size. Any unused functions are going to optimised out in the linker, but there is going to be a lot of new code here.
Proposal 2: Stick with the stdio/baremetal folder
In this alternative, we fill in every function that is implemented in the generic folder. This is the approach suggested by the linked PR.
This way, we don’t actually require a full FILE* interface, and we can easily optimise out for code size.
Thoughts
I do think that (1) is the cleaner approach, but I may have missed an approach. I would like to get started on this quite soon so I am open for any suggestions. Thank you for reading.