On Sun, 1 Aug 2021 15:39:25 +0200 "Ahmed S. Darwish" <a.darwish@xxxxxxxxxxxxx> wrote: > On Fri, Jul 30, 2021, Steven Rostedt wrote: > > + > > +The SQL format is as follows: > > + > > +*SELECT* <fields> FROM <start-event> JOIN <end-event> ON <matching-fields> WHERE <filter> > > + > > +Note, although the examples show the SQL commands in uppercase, they are not required to > > +be so. That is, you can use "SELECT" or "select" or "sElEct". > > + > > Maybe it would be helpful to mention that, unlike normal SELECT queries, > the JOIN and ON parts above are _not_ optional? > > That is, generic "one event source" queries: > > SELECT common_pid,msr,val FROM write_msr WHERE msr=72 > > are not supported. (I wish they were though ;-)) Actually, the sql parser should support it, but it will fail on the creation of events. That's because I started trying to make this create normal histograms. The problem is, that it can't really do a 1 to 1 on histograms and selects, so I gave up. But perhaps for the subset it can create, maybe I can still have it do so. That may require changing the API slightly. I'm not a big SQL person, so I don't know all the magic and I have no idea how to add the "values" part of the hist trigger. I could use SQL CAST to let people redefine the types that histograms allow, like: SELECT CAST(common_pid AS execname), CAST(id AS syscall) FROM sys_enter and have that produce: echo 'hist:keys=common_pid.execname,id.syscall' > events/raw_syscalls/sys_enter/trigger Any ideas for the syntax to get values? Or do people care about the value parameter any more than just "hitcount"? I don't think I have ever used it for anything. > > BTW, thanks a lot for this work. It will finally make synthetic events > usable! > Thanks! It's also something to make it easier for me to use. And hopefully, allow for even more complex synthetic events. -- Steve
|