On 6/23/22 12:52, Song Liu wrote: > On Thu, Jun 23, 2022 at 9:42 AM Daniel Bristot de Oliveira > <bristot@xxxxxxxxxx> wrote: >> >> On 6/22/22 09:24, Song Liu wrote: >>> This is interesting work! >>> >>> I applied the series on top of commit 78ca55889a549a9a194c6ec666836329b774ab6d >>> in upstream. Then, I got some compile/link error for CONFIG_RV_MON_WIP and >>> CONFIG_RV_MON_SAFE_WTD. I was able to compile the kernel with these two >>> configs disabled. >> >> I rebased the code and... it compiled. Maybe it was missing some >> config options that I forgot to set as "depends on" in the Kconfig. >> >> Can you check if it was the same problem automatically reported? >> >> Any further information here would help. I will revisit this. > > Here are the error messages I got: https://pastebin.com/zJxMA6RK , and > attached is the config file I used. > >> >> However, I hit the some issue with monitors/wwnr/enabled : >>> >>> [root@eth50-1 ~]# cd /sys/kernel/debug/tracing/rv/ >>> [root@eth50-1 rv]# cat available_monitors >>> wwnr >>> [root@eth50-1 rv]# echo wwnr > enabled_monitors >>> [root@eth50-1 rv]# cd monitors/ >>> [root@eth50-1 monitors]# cd wwnr/ >>> [root@eth50-1 wwnr]# ls >>> desc enable reactors >>> [root@eth50-1 wwnr]# cat enable >>> 1 >>> [root@eth50-1 wwnr]# echo 0 > enable <<< hangs >>> >>> The last echo command hangs forever on a qemu vm. I haven't figured out why >>> this happens though. >> >> I could reproduce it. It is an error in the return code of monitor_enable_write_data(), >> I fixed it locally (return retval ? retval : count; // needs more test), and >> will add it to the next version. Thanks! >> >>> I also have a more general question: can we do RV with BPF and simplify the >>> work? AFAICT, the idea of RV is to maintain a state machine based on events. >>> If something unexpected happens, call the reactor. >>> >>> IIUC, BPF has most of these building blocks ready for use. With BPF, we >>> can ship many RV monitors without much kernel changes. >> >> I am aware of bpftrace and bpf + libbpf, and I have a PoC tool doing most of the >> work I do in C/kernel in C/bpf. >> >> From the cover letter: >> >> "Things kept for a second moment (after this patchset): >> [...] >> - dot2bpf" >> >> The point is that there are use-cases in which the users need the code in >> C. One of those is the work being done in the Linux Foundation Elisa group. >> There will be more formalism, like timed automata... which will require >> infra-structure that is easily accessible in C... including synchronization, >> and reactors that are available only in C on "per use-cases" basis - for >> example on embedded devices. > > Where can I find more information about the constraints of these use cases? Check the LF elisa workgroup. > I am asking because there are multiple ways to load a BPF program to the > system. If the constraint is that we cannot have bpftrace or bcc in the system, > maybe it is ok to run a standalone binary (written in C, compiled on a different > system). as I said... *I am aware of that*. I do like BPF! I was already convinced I will having things in BPF :-) dot2bpf does stand alone application, C + libbpf (and I did it this way to have the most of flexibility), it works (for the things that are possible in BPF). It shares most of the work in C/kernel, I will add it in the second patch series. Or maybe we can load BPF programs in a kernel module, or compile > the BPF programs into the kernel? (Yes, we can do it now, check > kernel/bpf/preload). If any of these works, we can benefit from the good > properties of BPF. RV will take all these benefits, it is in the todo list as I said in this thread. But the in kernel version also has its facilities. For example, we can update the RV models without > rebooting the system; and we can reuse various BPF maps, so we don't > need to add union rv_task_monitor to task_struct. > > Of course, we are out of luck if these systems cannot enable CONFIG_BPF > at all. But I guess this is not common for modern embedded systems? I understand your motivations, and I agree with the benefits of BPF, but I also see benefits of having it in kernel as well. So, RV will go with both, they are not mutually exclusive. Thanks! -- Daniel > Thanks, > Song
