Integrate with kprobe

[zfdx123]

I noticed that the kernel code seems to use a patch to handle kernel implementation of ksu, but after testing it seems more convenient to use kprobe, would you consider switching to kprobe to reduce maintenance costs?

我注意到内核代码似乎使用了修补来处理内核实现ksu，但是经过测试使用kprobe似乎更方便，是否考虑跟换为kprobe降低维护成本？

[Rohail33]

I noticed that the kernel code seems to use a patch to handle kernel implementation of ksu, but after testing it seems more convenient to use kprobe, would you consider switching to kprobe to reduce maintenance costs?

我注意到内核代码似乎使用了修补来处理内核实现ksu，但是经过测试使用kprobe似乎更方便，是否考虑跟换为kprobe降低维护成本？

Well since Ksu isn't officially supported for non gki kernels... We are forced to use the manual patching to implement ksu... + Kprobes are broken on non mainline kernels it seems.

[zfdx123]

I noticed that the kernel code seems to use a patch to handle kernel implementation of ksu, but after testing it seems more convenient to use kprobe, would you consider switching to kprobe to reduce maintenance costs? 我注意到内核代码似乎使用了修补来处理内核实现ksu，但是经过测试使用kprobe似乎更方便，是否考虑跟换为kprobe降低维护成本？

Well since Ksu isn't officially supported for non gki kernels... We are forced to use the manual patching to implement ksu... + Kprobes are broken on non mainline kernels it seems.

It is not allowed to use two schemes at the same time in the official document, so I think we can get rid of the previously patched code and only use Kprobes, so that we can better choose whether to use ksu or not, just control it at compile time.

[Rohail33]

I noticed that the kernel code seems to use a patch to handle kernel implementation of ksu, but after testing it seems more convenient to use kprobe, would you consider switching to kprobe to reduce maintenance costs? 我注意到内核代码似乎使用了修补来处理内核实现ksu，但是经过测试使用kprobe似乎更方便，是否考虑跟换为kprobe降低维护成本？

Well since Ksu isn't officially supported for non gki kernels... We are forced to use the manual patching to implement ksu... + Kprobes are broken on non mainline kernels it seems.

It is not allowed to use two schemes at the same time in the official document, so I think we can get rid of the previously patched code and only use Kprobes, so that we can better choose whether to use ksu or not, just control it at compile time.

okeh thanks for pointing this out, gonna switch to kprobes, if they work fine on kona :)

[zfdx123]

I noticed that the kernel code seems to use a patch to handle kernel implementation of ksu, but after testing it seems more convenient to use kprobe, would you consider switching to kprobe to reduce maintenance costs? 我注意到内核代码似乎使用了修补来处理内核实现ksu，但是经过测试使用kprobe似乎更方便，是否考虑跟换为kprobe降低维护成本？

Well since Ksu isn't officially supported for non gki kernels... We are forced to use the manual patching to implement ksu... + Kprobes are broken on non mainline kernels it seems.

It is not allowed to use two schemes at the same time in the official document, so I think we can get rid of the previously patched code and only use Kprobes, so that we can better choose whether to use ksu or not, just control it at compile time.

okeh thanks for pointing this out, gonna switch to kprobes, if they work fine on kona :)

Thank you, dear developer. This is a piece of test code integrated with kprobes.

git clone https://github.com/tiann/KernelSU kernel-source/KernelSU
cd kernel-source
echo "CONFIG_KPROBES=y" >> ${{ inputs.config_path }}${{ inputs.config_name }}
echo "CONFIG_HAVE_KPROBES=y" >> ${{ inputs.config_path }}${{ inputs.config_name }}
echo "CONFIG_KPROBE_EVENTS=y" >> ${{ inputs.config_path }}${{ inputs.config_name }}
git config --global user.email "robot@example.com"
git config --global user.name "robot"
git add ${{ inputs.config_path }}${{ inputs.config_name }}
git commit -m "KUS"
./KernelSU/kernel/setup.sh main

https://github.com/zfdx123/build-k40-ksu/blob/f06a7706ad9a9aa6bda06f91c3e25df28c53713d/.github/workflows/build.yml#L81

[zfdx123]

I think this can reduce some upstream conflicts and solve some unnecessary problems.