On Thu, 2018-01-18 at 08:52 +0100, Uros Bizjak wrote: > This puts an extra burden on the developer, which has to use correct > thunk name in their code. Sure, this can be solved trivially with > #ifdef __x86_64__, so the issue is minor, but I thought it has to be > mentioned before the name is set in stone.
Except the developer can mostly use the inline thunk and not have to worry their pretty little heads about it. And the kernel developers who *have* chosen to implement their own thunk (and who requested the thunk-extern variant in the first place) have explicitly asked for the symbol name to be as it is. I spent a happy few hours on Sunday night looking at this. Seriously, in neither the thunk implementation nor the call sites (in explicit asm) was it easier. It was horrid — just look at the patch I sent out with the footnote "let's not do this". In the thunk I still had the actual register name with the 'e' or the 'r' in a macro argument anyway, because I had to deal with the value from that register. So the thunk macro ended up taking *two* arguments because its name now didn't match what it had to call the register. And in the call sites I was putting the target into a register again using either 'eax' or 'rax' form, then having to branch to the thunk using the different '_ax' form. It just hurt.
smime.p7s
Description: S/MIME cryptographic signature
