On Sun, 2018-01-14 at 21:21 +0100, Uros Bizjak wrote: > A quick look through latest x86/pti update [1] shows: > > +#ifdef CONFIG_X86_32 > +#define INDIRECT_THUNK(reg) extern asmlinkage void > __x86_indirect_thunk_e ## reg(void); > +#else > +#define INDIRECT_THUNK(reg) extern asmlinkage void > __x86_indirect_thunk_r ## reg(void); > +INDIRECT_THUNK(8) > +INDIRECT_THUNK(9) > +INDIRECT_THUNK(10) > +INDIRECT_THUNK(11) > +INDIRECT_THUNK(12) > +INDIRECT_THUNK(13) > +INDIRECT_THUNK(14) > +INDIRECT_THUNK(15) > +#endif > +INDIRECT_THUNK(ax) > +INDIRECT_THUNK(bx) > +INDIRECT_THUNK(cx) > +INDIRECT_THUNK(dx) > +INDIRECT_THUNK(si) > +INDIRECT_THUNK(di) > +INDIRECT_THUNK(bp) > +INDIRECT_THUNK(sp)
Yeah, that one is purely for the CONFIG_MODVERSIONS system, which I'm hoping to fix properly by not having to have fake (and clearly incorrect) C prototypes for the thunks which aren't actually C functions. It's intended to go away. > and: > > +/* > + * Despite being an assembler file we can't just use .irp here > + * because __KSYM_DEPS__ only uses the C preprocessor and would > + * only see one instance of "__x86_indirect_thunk_\reg" rather > + * than one per register with the correct names. So we do it > + * the simple and nasty way... > + */ > +#define EXPORT_THUNK(reg) EXPORT_SYMBOL(__x86_indirect_thunk_ ## reg) > +#define GENERATE_THUNK(reg) THUNK reg ; EXPORT_THUNK(reg) > + > +GENERATE_THUNK(_ASM_AX) > +GENERATE_THUNK(_ASM_BX) > +GENERATE_THUNK(_ASM_CX) > +GENERATE_THUNK(_ASM_DX) > +GENERATE_THUNK(_ASM_SI) > +GENERATE_THUNK(_ASM_DI) > +GENERATE_THUNK(_ASM_BP) > +GENERATE_THUNK(_ASM_SP) > +#ifdef CONFIG_64BIT > +GENERATE_THUNK(r8) > +GENERATE_THUNK(r9) > +GENERATE_THUNK(r10) > +GENERATE_THUNK(r11) > +GENERATE_THUNK(r12) > +GENERATE_THUNK(r13) > +GENERATE_THUNK(r14) > +GENERATE_THUNK(r15) > > I have a feeling that using e.g. __x86_indirect_thunk_ax would be more > convenient in both cases. Likewise, the CONFIG_TRIM_UNUSED_SYMBOLS mechanism in the kernel passes .S files through the preprocessor and looks for EXPORT_SYMBOL, so it wasn't working well with my .irp-based implementation like the one in Xen. So I've swapped it out for this one for now. Again, I was hoping to clean that up and make it do something saner, and then this could switch back too. But sure, right now it isn't that might of a difference for me; my implementation has changed since I made that reqeust. I have no fundamental technical objection to the bare 'ax' naming. We can live with either. It's just that we've been asking for an agreement on the basics (the command line we use, and the thunk names) for some days now, and this is the first time we've had this discussion, and Linus has just taken the patches. That's still fine. I know we get no sympathy, and we *can* change the Linux kernel between -rc8 and -final if we must, and change the Xen patches too. I'd just rather not.
smime.p7s
Description: S/MIME cryptographic signature