| Filename | Latest commit message | Latest commit date |
|---|---|---|
11141da623
Note:
2 == BPFLOADER_S_VERSION
19 == BPFLOADER_T_VERSION
25 == BPFLOADER_OBJ_AT_VER_VERSION
33 == BPFLOADER_IGNORED_ON_VERSION
37 == BPFLOADER_U_VERSION [*]
41 == BPFLOADER_V_VERSION [**]
and currently we have:
42 == BPFLOADER_MAINLINE_VERSION
43 == BPFLOADER_MAINLINE_T_VERSION
44 == BPFLOADER_MAINLINE_U_VERSION
45 == BPFLOADER_MAINLINE_V_VERSION
[*] udc-dev/udc-release are actually 38, as 37 was some earlier
udc beta2 (2.1 ifirc), and beta3+ switched to 38
[**] 24Q{1,2}-release (ie. U QPR2+) are technically actually 41,
but their platform bpfloader no longer even looks in /apex/com.android.tethering/etc/bpf/...
so it doesn't really matter (although 24Q1's platform
netbpfload still does, however that is obsoleted by
this change)
Thus we need to (as minimum for NetBpfLoad):
BPFLOADER_T_VERSION -> BPFLOADER_MAINLINE_T_VERSION
BPFLOADER_IGNORED_ON_VERSION -> BPFLOADER_MAINLINE_U_VERSION
to cause these to load appropriately from mainline.
One would perhaps also expect (as minimum for NetBpfLoad):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_U_VERSION
but (as maximum for platform bpfloader):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_U_VERSION
However, since the goal is actually for those to load via mainline on T+,
(with the 'old' version of the .o's loading on S via platform bpfloader)
thus one actually needs (as minimum for NetBpfLoad):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_T_VERSION
and (as maximum for platform bpfloader):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_T_VERSION
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4b688692ffca0db7ead20cefd9e7e892ca92c70a
|
||
| .. | ||
| bpf_headers | ||
| bpf_syscall_wrappers | ||
| bpfmapjni | ||
| bpfutiljni | ||
| ip_checksum | ||
| netjniutils | ||
| nettestutils | ||
| tcutils | ||
| README.md | ||
JNI
As a general rule, jarjar every static library dependency used in a mainline module into the modules's namespace (especially if it is also used by other modules)
Fully-qualified name of java class needs to be hard-coded into the JNI .so, because JNI_OnLoad does not take any parameters. This means that there needs to be a different .so target for each post-jarjared package, so for each module.
This is the guideline to provide JNI library shared with modules:
-
provide a common java library in frameworks/libs/net with the Java class (e.g. BpfMap.java).
-
provide a common native library in frameworks/libs/net with the JNI and provide the native register function with class_name parameter. See register_com_android_net_module_util_BpfMap function in frameworks/libs/net/common/native/bpfmapjni/com_android_net_module_util_BpfMap.cpp as an example.
When you want to use JNI library from frameworks/lib/net:
-
Each module includes the java library (e.g. net-utils-device-common-bpf) and applies its jarjar rules after build.
-
Each module creates a native library in their directory, which statically links against the common native library (e.g. libnet_utils_device_common_bpf), and calls the native registered function by hardcoding the post-jarjar class_name. Linkage MUST be static because common functions in the file (e.g.,
register_com_android_net_module_util_BpfMap) will appear in the library (.so) file, and different versions of the library loaded in the same process by different modules will in general have different versions. It's important that each of these libraries loads the common function from its own library. Static linkage should guarantee this because static linkage resolves symbols at build time, not runtime.