Playing with function hooks, I've found two issues that draw my ire. FYI, this is more of a partial experience report than a question. For an example, let us discuss the kernel function "pci_register_driver", which is actually a macro and thus not handled by the function hooks. The first step in fixing this is a CPP section: #c inline int pci_register_driver2(pci_dev_t d) { pci_register_driver(d); } #endc So I'd call this experience number 1 - it is entirely possible to automatically generate wrapper functions for macros ( {#macro ...}? or even {#fun ...} handling macros too). Perhaps there's not enough interest for anyone to make this change but I expect this to come up more and more often. I'll note that this is very similar to the issue of importing pure macros (macros that don't wrap a function call), which would be a nice feature. I can now write the hook and c2hs will parse things ok: {#fun pci_register_driver2 as ^ {id `PCIDriver' } -> `Int' id#} generating a foreign import: foreign import ccall safe "pci.chs.h pci_register_driver2" pciRegisterDriver'_ :: ((PCIDriver) -> (IO CInt)) And all seems well... except that I'm aiming to use this in interfacing with the Linux kernel. The generated *.chs.h file will/must be compiled into an object file using the Linux build system, which defaults to a regparm3 calling convention. Why does c2hs automatically assume its a ccall? I could really use an opportunity to insert an alternate convention. In the end the solution I have is to manually write the above C section and the foreign import call using a regparm3 calling convention. This isn't to say c2hs isn't used - its still hugely helpful (so long as the headers remain easy to convert to ANSI C), but just my quick experience. Thomas