Messages in this thread |  | | Date | Mon, 18 Apr 2022 22:43:29 +0200 | From | Hagen Paul Pfeifer <> | Subject | Re: [PATCH v8 00/12] user_events: Enable user processes to create and write to trace events |
| |
* Beau Belgrave | 2021-12-16 09:34:59 [-0800]:
>The typical scenario is on process start to mmap user_events_status. Processes >then register the events they plan to use via the REG ioctl. The ioctl reads >and updates the passed in user_reg struct. The status_index of the struct is >used to know the byte in the status page to check for that event. The >write_index of the struct is used to describe that event when writing out to >the fd that was used for the ioctl call. The data must always include this >index first when writing out data for an event. Data can be written either by >write() or by writev().
Hey Beau, a little bit late to the party. A few questions from my side: What are the exact weak points of USDT compared to User Events that stand in the way of further extend USDT (in a non-compatible way, sure, just as an different approach!)? The nice thing about USDT is that I can search for all possible probes of the system via "find / | readelf | ". Since they are listed in a dedicated ELF section (.note.stapsdt) - they are visible & transparent. I can also map a hierarchy/structure in Executable/DSO via clever choice of names. The big disadvantage of USDT is the lack of type information, but from a registration, explicit point of view, they are nice.
Or in other words: why not extends the USDT approach? Why not
u32 val = 23; const char *garbage = "tracestring";
DYNAMIC_TRACE_PROBE2("foo:bar", val, u32, garbage, cstring);
Sure, the argument names, here "val" and "garbage" should also be saved. I also like the "just one additional header to the project to get things running" (#include "sdt.h"). Sure, a DYNAMIC_TRACE_IS_ACTIVE("foo:bar") would be great. But in fact we have never needed that in the past.
hgn
|  |