move bpfloader.rc into p/m/C

Generated via:
  cat ../../../system/bpf/bpfloader/bpfloader.rc > netbpfload/netbpfload.rc

(plus changing Android.bp to use it)

Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4bcdd57b0b5abcc296a4c56273d6aac632560345

netbpfload/Android.bp

@@ -46,5 +46,6 @@ cc_binary {
     // min_sdk_version(30) for "com.android.tethering": newer SDK(34).
     min_sdk_version: "30",
 
-    // init_rc: ["netbpfload.rc"],
+    init_rc: ["netbpfload.rc"],
+    required: ["bpfloader"],
 }

netbpfload/netbpfload.rc

@@ -3,7 +3,7 @@
 # a tad earlier.  There's no benefit to that though, since on 4.9+ P+ devices netd
 # will just block until bpfloader finishes and sets the bpf.progs_loaded property.
 #
-# It is important that we start netbpfload after:
+# It is important that we start bpfloader after:
 #   - /sys/fs/bpf is already mounted,
 #   - apex (incl. rollback) is initialized (so that in the future we can load bpf
 #     programs shipped as part of apex mainline modules)
@@ -15,9 +15,10 @@
 # considered to have booted successfully.
 #
 on load_bpf_programs
-    exec_start netbpfload
+    exec_start bpfloader
 
-service netbpfload /system/bin/netbpfload
+service bpfloader /system/bin/netbpfload
+    # netbpfload will do network bpf loading, then execute /system/bin/bpfloader
     capabilities CHOWN SYS_ADMIN NET_ADMIN
     # The following group memberships are a workaround for lack of DAC_OVERRIDE
     # and allow us to open (among other things) files that we created and are
@@ -27,28 +28,28 @@ service netbpfload /system/bin/netbpfload
     group root graphics network_stack net_admin net_bw_acct net_bw_stats net_raw system
     user root
     #
-    # Set RLIMIT_MEMLOCK to 1GiB for netbpfload
+    # Set RLIMIT_MEMLOCK to 1GiB for bpfloader
     #
-    # Actually only 8MiB would be needed if netbpfload ran as its own uid.
+    # Actually only 8MiB would be needed if bpfloader ran as its own uid.
     #
     # However, while the rlimit is per-thread, the accounting is system wide.
     # So, for example, if the graphics stack has already allocated 10MiB of
-    # memlock data before netbpfload even gets a chance to run, it would fail
+    # memlock data before bpfloader even gets a chance to run, it would fail
     # if its memlock rlimit is only 8MiB - since there would be none left for it.
     #
-    # netbpfload succeeding is critical to system health, since a failure will
+    # bpfloader succeeding is critical to system health, since a failure will
     # cause netd crashloop and thus system server crashloop... and the only
     # recovery is a full kernel reboot.
     #
     # We've had issues where devices would sometimes (rarely) boot into
-    # a crashloop because netbpfload would occasionally lose a boot time
+    # a crashloop because bpfloader would occasionally lose a boot time
     # race against the graphics stack's boot time locked memory allocation.
     #
-    # Thus netbpfload's memlock has to be 8MB higher then the locked memory
+    # Thus bpfloader's memlock has to be 8MB higher then the locked memory
     # consumption of the root uid anywhere else in the system...
     # But we don't know what that is for all possible devices...
     #
-    # Ideally, we'd simply grant netbpfload the IPC_LOCK capability and it
+    # Ideally, we'd simply grant bpfloader the IPC_LOCK capability and it
     # would simply ignore it's memlock rlimit... but it turns that this
     # capability is not even checked by the kernel's bpf system call.
     #
@@ -57,29 +58,29 @@ service netbpfload /system/bin/netbpfload
     rlimit memlock 1073741824 1073741824
     oneshot
     #
-    # How to debug bootloops caused by 'netbpfload-failed'.
+    # How to debug bootloops caused by 'bpfloader-failed'.
     #
     # 1. On some lower RAM devices (like wembley) you may need to first enable developer mode
     #    (from the Settings app UI), and change the developer option "Logger buffer sizes"
     #    from the default (wembley: 64kB) to the maximum (1M) per log buffer.
     #    Otherwise buffer will overflow before you manage to dump it and you'll get useless logs.
     #
-    # 2. comment out 'reboot_on_failure reboot,netbpfload-failed' below
+    # 2. comment out 'reboot_on_failure reboot,bpfloader-failed' below
     # 3. rebuild/reflash/reboot
-    # 4. as the device is booting up capture netbpfload logs via:
-    #    adb logcat -s 'NetBpfLoad:*' 'NetBpfLoader:*'
+    # 4. as the device is booting up capture bpfloader logs via:
+    #    adb logcat -s 'bpfloader:*' 'LibBpfLoader:*' 'NetBpfLoad:*' 'NetBpfLoader:*'
     #
     # something like:
-    #   $ adb reboot; sleep 1; adb wait-for-device; adb root; sleep 1; adb wait-for-device; adb logcat -s 'NetBpfLoad:*' 'NetBpfLoader:*'
+    #   $ adb reboot; sleep 1; adb wait-for-device; adb root; sleep 1; adb wait-for-device; adb logcat -s 'bpfloader:*' 'LibBpfLoader:*' 'NetBpfLoad:*' 'NetBpfLoader:*'
     # will take care of capturing logs as early as possible
     #
-    # 5. look through the logs from the kernel's bpf verifier that netbpfload dumps out,
+    # 5. look through the logs from the kernel's bpf verifier that bpfloader dumps out,
     #    it usually makes sense to search back from the end and find the particular
-    #    bpf verifier failure that caused netbpfload to terminate early with an error code.
+    #    bpf verifier failure that caused bpfloader to terminate early with an error code.
     #    This will probably be something along the lines of 'too many jumps' or
     #    'cannot prove return value is 0 or 1' or 'unsupported / unknown operation / helper',
     #    'invalid bpf_context access', etc.
     #
-    reboot_on_failure reboot,netbpfload-failed
+    reboot_on_failure reboot,bpfloader-failed
     # we're not really updatable, but want to be able to load bpf programs shipped in apexes
     updatable