lkml.org 
[lkml]   [2019]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH 10/15] static_call: Add basic static call infrastructure
    Date
    > On Jun 7, 2019, at 1:49 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
    >
    > On Fri, 7 Jun 2019 at 10:29, Peter Zijlstra <peterz@infradead.org> 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Fardb%2Flinux.git%2Flog%2F%3Fh%3Dstatic-calls&amp;data=02%7C01%7Cnamit%40vmware.com%7Cd31c4713640c44a651bf08d6eb250faa%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636954941771964758&amp;sdata=h7RtT33E9FMapLZbAu9aTfjREP5kXrM0o2QQ1WpbDCM%3D&amp;reserved=0
    >
    > but IIRC, all it does is annotate call sites exactly how objtool does it.

    I did not see your version before I made mine for a similar (but slightly
    different) purpose:

    https://lore.kernel.org/lkml/20181231072112.21051-4-namit@vmware.com/

    My version, I think, is more generic (I don’t think yours consider calls
    that have a return value). Anyhow, I am sure you know more about GCC plugins
    than I do.

    I do have a version that can take annotations to say which call should be
    static and to get the symbol it uses.

    I also think that this implementation would disallow keys that reside within
    structs. This would mean that paravirt, for instance, would need to go
    through many changes to use this infrastructure.

    \
     
     \ /
      Last update: 2019-06-07 18:59    [W:6.380 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site