Hi Simon, thanks for the reply! What I came up with for now is this example <https://github.com/ImMax/babeltrace/commit/2082a0f4d77d2edeec6fb95c308a79fb313f7a02>. It's probably has a lot of design mistakes but it's at least runnable. I also see that examples for C API aren't build, but maybe I'm wrong. Another thing, if you have lack of resources I would be happy to help, I could make a PR with your guidance and review.
Answers to the questions: 1) Not sure that I completely understand the question, I wanted to parse events(name, fields), not the metadata file aligned with the CTF trace file. 2) Because I wanted to get C-structs directly from the CTF traces. I'm sure that it's very niche requirement, sane people would not need it. 3) I would do something like that, but I have a requirement of providing C structs. I guess to apply filters or do something else with traces (I'm not sure, not my idea, but I also find it weird) On Fri, 19 Aug 2022 at 17:00, Simon Marchi <sim...@simark.ca> wrote: > On 8/12/22 09:19, Maksim Khmelevskiy via lttng-dev wrote: > > Hi, > > > > > there is a nice py message iterator example > > <https://babeltrace.org/docs/v2.0/python/bt2/examples.html> but for C > > API only plugins are covered with examples, do you think it would make > > sense to create an example of a standalone application which simply > > uses `source.ctf.fs` as source and iterates over all messages? It > > would be nice hint for those who want to see an example of graph > > creation with all the code in one file. > > Hi Maksim, > > I'm not sure which example you are referring to exactly. But in Python, > we have the high-level TraceCollectionMessageIterator object, which does > roughly: > > - Instantiate source and filter components according to the provided > specs, including automatic source discovery > - Instantiate a flt.utils.muxer component to merge the streams from all > sources ports > - Instantiate a sink component that presents the events as a Python > iterable > - Connect the ports of all these components > - More things that are irrelevant here > > There is no such high-level object in the C interface, so you have > to do all this by hand, it will necessarily be much more verbose. It > would be nice to have the equivalent of TraceCollectionMessageIterator > in the C API, it is just not done yet due to lack of resources. > > I did search in the documentation for an example program that uses the C > API to create and run a graph, and I haven't found one. I agree that > adding one would be nice. I'll look into writing one. > > Regarding your use case: > > > I'm interested in that example because I want to transform CTF file > > into list of C structures representing messages. > > I have some questions: > > - Is the data you want to convert found in the metadata of the traces > (description of event types) of in the payload of events? > - Why do you want to write this in C instead of Python? It sounds like > it would be much faster to write in Python (with > TraceCollectionMessageIterator), and it doesn't sound like something > where the performance is critical (but of course I don't have the > full context). > - Why do you need to write an application where you create and run the > graph yourself? Could you instead just write your sink component > class (which reads the messages and writes your output files), > packaged in a plugin and use it through the babeltrace2 command-line: > > $ babeltrace2 /path/to/ctf/trace -c sink.foo.bar -p 'output="out.h"' > > ? This way, you just have to care about writing your component > class, which does the conversion you need. > > Simon >
_______________________________________________ lttng-dev mailing list lttng-dev@lists.lttng.org https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
