This excerpt from a post by Duane Rettig seems at least slighty relevant to standard FFI and automatic FFI generation:

For #3, I was almost ready to disagree with Thomas Bushnell because I believed that it is necessary to use C functionality to interface to C library functions. This is especially true for the need to parse .h files, and to get the correct definitions and interfaces based on particular #define constants. If you doubt this, just try to figure out, for example, HP's sigcontext structure, which has layer upon layer of C macrology to define a large number of incompatible structure and interface definitions.

However, I had to back off on any such disagreement, becuase it certainly is _possible_ to write any of these interface functions in lisp, using such facilities as our Cbind tool to pre-parse the header files and to thus present all pertinent information to the lisp-in-lisp code. However, I still am not inclined to do such a thing, because it would be specialized toward lisp bootstrap, and thus not useful for anything else. And why not use C at what it does best (parse C header files)? Besides, even our Cbind facility uses the gcc front-end to do the initial parsing, so in essence a non-lisp compiler part would still be used. Bottom line; it is more convenient to write our os-interface code in C, because it interfaces to C libraries. I suppose that we would remove such C interfaces if we were porting our lisp to a Lisp operatring system.