fche changed the topic of #systemtap to: http://sourceware.org/systemtap; email systemtap@sourceware.org if answers here not timely, conversations may be logged
hpt has joined #systemtap
lijunlong has quit [Read error: Connection reset by peer]
lijunlong has joined #systemtap
hpt has quit [Ping timeout: 240 seconds]
khaled has quit [Quit: Konversation terminated!]
orivej has joined #systemtap
khaled has joined #systemtap
amerey_ has quit [Remote host closed the connection]
amerey_ has joined #systemtap
fdalleau_away has quit [*.net *.split]
kerneltoast has quit [*.net *.split]
kerneltoast has joined #systemtap
fdalleau_away has joined #systemtap
khaled has quit [Ping timeout: 240 seconds]
khaled has joined #systemtap
orivej has quit [Ping timeout: 246 seconds]
orivej has joined #systemtap
orivej has quit [Ping timeout: 260 seconds]
<agentzh>
fche, serhei: i've just noted the bpf_interpret() func in stapbpf. it looks like a userland bpf interpreter. is it stap's secret weapon to bypass the kernel verifier?
<agentzh>
or to bypass the lack of certain bpf helpers in the kernel?
<fche>
SSShhhhhhh
<fche>
say nothing
<fche>
agentzh, it's for running probe types that the kernel can't or won't
<fche>
like timer or begin/end probes
<fche>
it can't take the place of kernel side bpf like kprobes/tracepoint-triggered things
<fche>
but probe begin/end, with loops etc., can run in userspace
<agentzh>
lol
<agentzh>
i see.
<agentzh>
seems like it won't be possible to read any kernel data in begin/end probes then?
<agentzh>
and also timer probes?
<agentzh>
yeah, i saw it is only applied to procfs probes and begin/end/error probes.
<agentzh>
so timer probes are considered "procfs probes"?
amerey_ has quit [Remote host closed the connection]