On Fri, 7 Jun 2019 at 10:29, Peter Zijlstra <[email protected]> wrote: > > On Thu, Jun 06, 2019 at 10:44:23PM +0000, Nadav Amit wrote: > > > + * Usage example: > > > + * > > > + * # Start with the following functions (with identical prototypes): > > > + * int func_a(int arg1, int arg2); > > > + * int func_b(int arg1, int arg2); > > > + * > > > + * # Define a 'my_key' reference, associated with func_a() by default > > > + * DEFINE_STATIC_CALL(my_key, func_a); > > > + * > > > + * # Call func_a() > > > + * static_call(my_key, arg1, arg2); > > > + * > > > + * # Update 'my_key' to point to func_b() > > > + * static_call_update(my_key, func_b); > > > + * > > > + * # Call func_b() > > > + * static_call(my_key, arg1, arg2); > > > > I think that this calling interface is not very intuitive. > > Yeah, it is somewhat unfortunate.. >
Another thing I brought up at the time is that it would be useful to have the ability to 'reset' a static call to its default target. E.g., for crypto modules that implement an accelerated version of a library interface, removing the module should revert those call sites back to the original target, without putting a disproportionate burden on the module itself to implement the logic to support this. > > I understand that > > the macros/objtool cannot allow the calling interface to be completely > > transparent (as compiler plugin could). But, can the macros be used to > > paste the key with the “static_call”? I think that having something like: > > > > static_call__func(arg1, arg2) > > > > Is more readable than > > > > static_call(func, arg1, arg2) > > Doesn't really make it much better for me; I think I'd prefer to switch > to the GCC plugin scheme over this. ISTR there being some propotypes > there, but I couldn't quickly locate them. > I implemented the GCC plugin here https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=static-calls but IIRC, all it does is annotate call sites exactly how objtool does it. > > > +} > > > + > > > +#define static_call_update(key, func) > > > \ > > > +({ \ > > > + BUILD_BUG_ON(!__same_type(func, STATIC_CALL_TRAMP(key))); \ > > > + __static_call_update(&key, func); \ > > > +}) > > > > Is this safe against concurrent module removal? > > It is for CONFIG_MODULE=n :-)

