On Mon, Feb 14, 2022 at 9:27 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Fri, Feb 11, 2022 at 05:16:25PM -0800, Andrii Nakryiko wrote: > > > > > > Calling the callback 'preload' when it cannot affect the load is odd too. > > > > It's what happening before loading, I never had intention to prevent > > load... Would "prepare_load_fn" be a better name? > > prepare_load_fn would be more accurate name for sure. SGTM, I'll rename > > If we're not planning to change place where init_fn is called too > then can we rename it to something that would accurately describe it? > It seems it's called after ELF is fully parsed except relos and progs > are ready to be tweaked. > Should 'prog' be in the name? Like prog_setup_fn ? or prog_init_fn ? > Then ability to set prog autoload would flow naturally from such name. > What else can be done there? Or what is a recommended use of this cb? I like prog_setup_fn name, it matches semantics very closely. It is supposed to be able to do everything that user can do though all the bpf_program getters/setters before bpf_object__load() step. If some of those setters doesn't work from prog_setup_fn(), we'll fix that, but otherwise I think it will always be a "post-bpf_object__open()" callback to adjust whatever libbpf does by default. > > > might what to be able to do with this. Alan's uprobe attach by > > function name would be implementable through these APIs outside of > > libbpf as well (except then we won't be able to add func_name into > > bpf_uprobe_opts, which would be a pity). > > Alan, > can you demo your "okprobe" feature based on this api? > Any rough patches would do. > The "o" handling will be done in which callback?
