I think the bpf_printk output should not be sent to the shm. We can use a name pipe.

It can be similar like kernel /sys/kernel/debug/tracing/trace_pipe

The cli can read the data from the pipe, and the pipe can also be shared between processes.

And maybe all the log from bpftime runtime should also be sent to the name pipe for debug.

+1. I hope the bpf_printk's output goes to the stderr stream of the bpftime load program so that it's easier to separate the debugging output from the normal output data currently going to stdout.

Hello, I am new to the code, and had a doubt after reading the issue comments and the code - Will the cli have a new option for reading the data from the pipe?

Hello, I am new to the code, and had a doubt after reading the issue comments and the code - Will the cli have a new option for reading the data from the pipe?

Yes

I think it is an interesting issue, and would love to explore more. Also, would the implementation of bpf_printk change, or will there be a new function to write in the tracepipe?

I think it is an interesting issue, and would love to explore more. Also, would the implementation of bpf_printk change, or will there be a new function to write in the tracepipe?

bpf_printk should keep its current function, but we could use attach config (such as an option when invoking bpftime attach) to make bpf_printk output things to the pipe

I read more on the issue and referring to: https://eunomia.dev/bpftime/documents/usage/#uprobe-and-uretprobe, bpf_printk's result is shown in the output of the target (victim) program a) when it is called with the start option, or b) when the attach option works on the PID.
Hence, start and attach are responsible for dealing with bpf_printk's results.
I read some corresponding code and tried to identify the areas where tracelog is being read. Could you please help with any areas in the code I could concentrate on further?

I read more on the issue and referring to: https://eunomia.dev/bpftime/documents/usage/#uprobe-and-uretprobe, bpf_printk's result is shown in the output of the target (victim) program a) when it is called with the start option, or b) when the attach option works on the PID. Hence, start and attach are responsible for dealing with bpf_printk's results. I read some corresponding code and tried to identify the areas where tracelog is being read. Could you please help with any areas in the code I could concentrate on further?

bpf_trace_printk (which is the function that bpf_printk internally calls), is a bpf helper implemented at

In both bpftime start and bpftime attach, the agent was injected to the process that we want to monitor. So in the current implementation, call to bpf_trace_printk will result a message printed to stdout, at the process that was injected with agent