[Part-1] native module changes for per-instance load #4175
Conversation
saxena-anurag
changed the title
saxena-anurag
changed the title
saxena-anurag
requested review from
dthaler,
poornagmsft,
Alan-Jowett,
shankarseal,
dv-msft,
matthewige and
mtfriesen
as code owners
|
Still working on making |
The tests are all fixed now. |
| @@ -1233,7 +1233,8 @@ bpf_code_generator::bpf_code_generator_program::encode_instructions( | |||
| throw bpf_code_generator_exception( | |||
| "Map " + output.relocation + " doesn't exist", output.instruction_offset); | |||
| } | |||
| source = std::format("_maps[{}].address", std::to_string(map_definition->second.index)); | |||
| source = | |||
| std::format("runtime_context->map_data[{}].address", std::to_string(map_definition->second.index)); | |||
There was a problem hiding this comment.
Since generated code is changing, please reflect that in the NativeCodeGeneration.md.
|
|
||
| static void | ||
| _ebpf_native_clean_up_programs( | ||
| _In_reads_(count_of_programs) ebpf_native_program_t** programs, size_t count_of_programs, bool close_handles) |
There was a problem hiding this comment.
Just double checking - are we guaranteed that programs is always non-null?
There was a problem hiding this comment.
Seems like it. If it isn't, the SAL annotation here should cause the compiler to complain.
There was a problem hiding this comment.
I checked and all callers as passing non-null.
| } helper_function_entry_t; | ||
|
|
||
| typedef struct _helper_function_data | ||
| { |
There was a problem hiding this comment.
Why are helper addresses per instance?
There was a problem hiding this comment.
As discussed offline, right now it does not make much difference. But to keep the code future proof (say, for scenarios when we want to support helper function per attach type), it is better to keep the per-instance data in the runtime context.
|
|
||
| static void | ||
| _ebpf_native_clean_up_programs( | ||
| _In_reads_(count_of_programs) ebpf_native_program_t** programs, size_t count_of_programs, bool close_handles) |
There was a problem hiding this comment.
Seems like it. If it isn't, the SAL annotation here should cause the compiler to complain.
…thub.com/saxena-anurag/ebpf-for-windows-1 into user/anusa/multiple_load_native_module_2
Fixes part of #2667
Description
This PR contains part-1 of the changes needed to support multiple-load of native modules.
Corresponding user mode changes, and the multiple load support will be added in a follow-up PR.
P.S.: Since 0.21 will have breaking changes for native module NMR interface, and this change it also disruptive, frontloading this part of the change, so that this can go in 0.21 release.
Testing
No functional change. Existing CICD should cover any regressions.
Documentation
No
Installation
No.