[libc-commits] [libc] [libc] Export the RPC interface from `libc` (PR #71432)

Joseph Huber via libc-commits libc-commits at lists.llvm.org
Thu Nov 9 14:08:39 PST 2023


jhuber6 wrote:

> The implementation has reinterpret cast all over the place and shouldn't. Declare the port as something like

Exporting an opaque handle is a pretty common idiom. The interface is completely hidden from the user, they just need to know it's data. Doing bit casts should be legal here.

> There's a fundamental layering violation in what we've done here which is probably the root cause of the API grief.
> 
> Libc _depends on_ syscall, libc _does not contain_ syscall. We should aspire to put the RPC machinery somewhere else, leave the implementation of fopen and similar in libc, but have the templated state machine exist independent of the exported API constructs of libc. It's a good candidate for some interpretations of llvm/offload.
> 

Somewhat agree in the long term. The general issue is then who's running the show in the case of a separate implementation. Maybe we could just make the actual client `weak_odr` and merge all references to it from its implementation in some `.cpp` file somewhere. Though it would be somewhat painful to link an external project in the tests.

> Suggest we take the bits of rpc that would be nice to export in type safe, non-function-pointery fashion and make those usable in a header only sense, not wire it up into libc's interface, and #include them from within openmp or whatever with total disregard to the exported C interface until such time as they have a new home.

This whole interface could be exported as `send_n` and `recv_n` if nothing else. That would require the user providing their own buffer. Could go that route instead for the time being. As it stands it's much more work to do any other restructuring.

https://github.com/llvm/llvm-project/pull/71432


More information about the libc-commits mailing list