<div dir="ltr"><div>Hi libcamera developers,</div><div><br></div><div>I've consulted with Google Perfetto team, and yes, we agree</div><div>that it makes more sense to have one debugging tool as the</div><div>source of truth and generate code for the other tool, to ease</div><div>the development effort in the future.</div><div><br></div><div>Please also share your concerns on the two approaches:</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 14, 2024 at 1:14 AM Lalit Maganti <<a href="mailto:lalitm@google.com">lalitm@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Sept 2024 at 18:08, Cheng-Hao Yang <<a href="mailto:chenghaoyang@google.com" target="_blank">chenghaoyang@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Thank you Lalit for the quick and thorough response,<br><br>Do you mind if I directly forward your messages to libcamera upstream directly?</div><div dir="ltr">I'll wait for a couple of days until everyone has the chance to speak out, and do a brief summary though.<br></div></div></blockquote><div><br></div><div>Sure that sounds good.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Responses inline:</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 13, 2024 at 6:19 PM Lalit Maganti <<a href="mailto:lalitm@google.com" target="_blank">lalitm@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Also <span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:ddiproietto@google.com" style="color:rgb(17,85,204);text-decoration:underline" target="_blank">+Daniele Di Proietto</a></span><span> is the C SDK better at being closer to LTTng in ethos? I know it allows e.g. defining custom protos directly in code and writing out those? Would that be a better fit for what these folks are trying to do?</span></div></blockquote><div><br>Yeah I forgot to mention that at least in CrOS, we're using cros-built Perfetto C SDK in libcamera.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Sept 2024, 10:54 Lalit Maganti, <<a href="mailto:lalitm@google.com" target="_blank">lalitm@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Please do feel free to setup some time with us (you can book slots at <a href="https://goto.google.com/perfetto-office-hours" rel="noreferrer" target="_blank">go/perfetto-office-hours</a>) or reach out by IM btw to speed iteration on this up if you have more questions/want to discuss more.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Sept 2024 at 10:53, Lalit Maganti <<a href="mailto:lalitm@google.com" rel="noreferrer" target="_blank">lalitm@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">Hi Harvey,<div><br></div><div>Responses inline.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 13 Sept 2024 at 08:56, Cheng-Hao Yang <<a href="mailto:chenghaoyang@google.com" rel="noreferrer" target="_blank">chenghaoyang@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> Hi Primiano and Perfetto developers,<br><br>This is Harvey, working in CrOS Camera team on <a href="https://libcamera.org/" rel="noreferrer" target="_blank">libcamera project</a>. I need some help from you, as I'm working on supporting Perfetto in libcamera upstream, which currently uses lttng as the tracing tool. Libcamera upstream has the concern that Perfetto is not added in the package repositories in linux distributions, and the way to build it in linux doesn't match the philosophy of Linux distributions.<div><br></div><div>We're considering supporting both tracing tools in libcamera, while libcamera upstream strongly prefers to have only one source of truth, which means to maintain only one version of trace macros/configs, and generate macros for the other (or both of them). This email thread contains the <a href="https://patchwork.libcamera.org/patch/18040/" rel="noreferrer" target="_blank">patch</a> of 3rd approach listed below.<br><br>I need your help on mainly two things:<br>1. An official reply to confirm that it is or isn't a priority to add Perfetto in the package repositories in linux distributions (I assume it isn't though). After providing this info, I can confirm with libcamera upstream our consensus of Perfetto support and responsibilities in the future.<br></div></div></blockquote><div><br></div><div>It is not a priority (and historically not been a priority) *but* at least for Debian we already did a bunch of the work to make a package for distributing Perfetto (see <a href="https://source.corp.google.com/h/android/platform/superproject/main/+/main:external/perfetto/debian/;l=1?q=f:perfetto%20f:debian&sq=repo:android%2Fplatform%2Fsuperproject%2Fmain%20b:main" rel="noreferrer" target="_blank">here</a>). If someone from your side was willing to do the work to submit this package, we'd be happy to keep it updated and maintained going forward.</div><div><br></div><div>So for us:<br><ol><li>Is someone from your side willing to take the work we've done and push it to completion?</li><li>Are there any other distros apart from Debian which libcamera would need us to be in?</li></ol></div></div></div></blockquote></div></blockquote></div></blockquote><div>1. Unfortunately, I don't think we have the bandwidth to help push it to completion in the current stage...</div><div>2. I believe there are at least Fedora and Raspberry. I'll let the libcamera upstream developers correct me.<br></div></div></div></blockquote><div><br></div><div>That's fair. I think in that case, it would be difficult for us to get it supported to the level that they want as well unfortunately. We're already resource constrained as it is and with Android and AL work, I don't think we'll have the bandwidth to deal with all the work for upstreaming into debian and all the other distros.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2. Take a brief look at the approaches below, and check if I missed something. You may focus on the 1st or 5th, which I'm currently inclined with. </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br>Here's the list of approaches that we can think of:<br><br><div>1. Generate Perfetto code from lttng macros.<br>  Pros: Easy to update libcamera tracepoint macros.</div><div>  Cons: Add maintenance work with the additional parser and code </div><div>generator; hard to implement Perfetto features that lttng doesn't have.</div></div></div></blockquote><div><br></div><div>An option but as you say, it does not support a bunch of features in Perfetto which LTTNG does not have.</div><div></div></div></div></blockquote></div></blockquote></div></blockquote></div></div></blockquote></div></div></blockquote><div><br></div><div>This one, which you might prefer.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div><div>2. Create a new language/config from which we generate both Perfetto</div><div>and lttng macros.</div><div>  Pros: Easy to update libcamera tracepoint macros.</div><div>  Cons: Probably an overkill; hard to cover all features from both </div><div>Perfetto and lttng.</div></div></div></blockquote><div><br></div><div>Yeah would not go here. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>3. As this patch implements: have duplicated libcamera tracepoint </div><div>definitions.</div><div>  Pros: Easy to add libcamera tracepoint macros to cover all features</div><div>from Perfetto & lttng.</div><div>  Cons: Developer needs to update both sides when the definition of</div><div>libcamera tracepoints changes; Unused macro definitions might be</div><div>adopted in both sides, if a feature is only available in one trace library.</div></div></div></blockquote><div><br></div><div>Inevitably things would get out of sync, I can see why they are against this.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>4. Add another set of libcamera tracepoints for Perfetto, or just use </div><div>Perfetto macros directly in libcamera's source code.</div><div>  Pros: Two isolated trace stacks that don't influence each other. All</div><div>features can be implemented easily.</div><div>  Cons: Duplicated trace code in source code that might lead to </div><div>confusion; developers also need to update both macros when a</div><div>new trace is needed.<br></div></div></div></blockquote><div><br></div><div>As above, same deal. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>5. Add libcamera macro usages, and generate lttng macros with codegen.<br>  Pros: It supports all perfetto features.<br>  Cons: Some lttng-only features (like ctf_integer_hex and ctf_enum)</div><div>are not available without weird hacks.<br></div></div></div></blockquote><div><br></div><div>If there are things like this, I think we'd be happy to work with you on getting those gaps resolved (if it's feasible, I haven't looked into the details in this particular case, it might not be).</div></div></div></blockquote></div></blockquote></div></blockquote><div><br>Yeah it might be the best case for us now.<br></div></div></div></blockquote><div><br></div><div>Cool sounds good :)</div></div></div></blockquote><div><br></div><div>Or this one, that Google prefers. We might need to find</div><div>a way to support hex & enum in this case though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>--------------<br><br>As libcamera upstream has a strong opinion, I might end up going with the 1st or 5th approach. The reason to consider the 1st is that currently the libcamera trace points might be better off with Perfetto counters (or slices with minimum lifetime), instead of slices. Please correct me if I'm wrong, but I think Perfetto slices are most useful for nested function calls. However, a lot of libcamera operations are triggered by callbacks (in libcamera, Signal).</div><div>I tried Perfetto flow yesterday, and it works on libcamera. We can possibly add a hack in the potential codegen to set it up though. </div></div></div></blockquote><div><br></div><div>Perfetto slices are not just for sync function calls: you can create synthetic sync stacks from them based on callback lifecycles: in Chrome/ChromeOS where everything is based on TaskRunner (thread loops) and callbacks, Perfetto is used very extensively and along with flows, allows visualizing async stuff just fine.</div><div><br></div><div>Counters are not a good fit for visualizing latencies of things which given the nature of libcamera is almost certainly what you want.</div></div></div></blockquote></div></blockquote></div></blockquote><div><br></div><div>Thanks for the info! Flow is very useful indeed. I'll do some more studies on the synthetic sync stacks, and check the best way to add traces in libcamera. It might be very different from the current lttng ones though, I believe.<br></div></div></div></blockquote><div><br></div><div>I mean an option here is to do LTTNG -> Perfetto conversion and then add some custom instrumentation in the places where it really helps having custom Perfetto instrumentation maybe? Maybe the libcamera folk would be more amenable to that?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Let me know if there's anything I haven't clarified yet.<br><br>Many thanks!<br>Harvey<br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Laurent Pinchart</strong> <span dir="auto"><<a href="mailto:laurent.pinchart@ideasonboard.com" rel="noreferrer" target="_blank">laurent.pinchart@ideasonboard.com</a>></span><br>Date: Wed, Sep 11, 2024 at 7:10 PM<br>Subject: Re: [libcamera-devel] [PATCH v3 1/1] Use tracing with perfetto in ChromeOS<br>To: Cheng-Hao Yang <<a href="mailto:chenghaoyang@chromium.org" rel="noreferrer" target="_blank">chenghaoyang@chromium.org</a>><br>Cc: Paul Elder <<a href="mailto:paul.elder@ideasonboard.com" rel="noreferrer" target="_blank">paul.elder@ideasonboard.com</a>>, Chinglin Yu <<a href="mailto:chinglinyu@chromium.org" rel="noreferrer" target="_blank">chinglinyu@chromium.org</a>>,  <<a href="mailto:libcamera-devel@lists.libcamera.org" rel="noreferrer" target="_blank">libcamera-devel@lists.libcamera.org</a>>, Harvey Yang <<a href="mailto:chenghaoyang@google.com" rel="noreferrer" target="_blank">chenghaoyang@google.com</a>><br></div><br><br>Hi Harvey,<br>
<br>
On Wed, Sep 11, 2024 at 06:05:18PM +0800, Cheng-Hao Yang wrote:<br>
> On Tue, Sep 10, 2024 at 12:30 AM Paul Elder wrote:<br>
> > Hi Harvey,<br>
> ><br>
> > <snip><br>
> ><br>
> > >     So in lttng we have a TRACEPOINT_EVENT_CLASS, which defines arguments<br>
> > >     and fields and how to obtain the fields from the args. We can<br>
> > >     instantiate tracepoints with TRACEPOINT_EVENT_INSTANCE, where we only<br>
> > >     have to specify the args, and the fields are already defined and come<br>
> > >     from the class. This reduces duplication in the tracepoint definitions.<br>
> > ><br>
> > >     I'm wondering from what you've implemented here that perfetto doesn't<br>
> > >     support this? I don't see anything in the perfetto docs that suggest<br>
> > >     that this is possible either. Although we can mitigate this issue by<br>
> > >     generating the perfetto tracepoints :) (this is another reason why I<br>
> > >     think we should use the lttng tracepoints definition as the main one and<br>
> > >     generate the perfetto ones from those)<br></div></div></div></blockquote><div><br></div><div>The LTTNG model is very very different from the Perfetto model. For us, the equivalent of LTTNG "tracepoints" are defined directly in Perfetto source code. You wouldn't see it on the libcamera side as you use the macros to directly write these (they're really protos) without having a "definition" in the libcamera source code.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote">
> > ><br>
> > > I've discussed with ChromeOS Perfetto TL chinglinyu@, and we found that<br>
> > > there are limited features in lttng [1], and if we use the lttng tracepoints<br>
> > > definition as the source of truth, it's hard/weird to implement some Perfetto<br>
> > > concepts, like nested slices (lifetime of trace events) and flows [2].<br>
> ><br>
> > Ah ok, I see the problem.<br>
> ><br>
> > > It's not impossible, as you mentioned above, that we could detect the prefix<br>
> > > and suffix of each libcamera/lttng macro. However, it's a weird code parser<br>
> > > and generator design.<br>
> > ><br>
> > > [1]: <a href="https://lttng.org/man/3/lttng-ust/v2.8/" rel="noreferrer noreferrer" target="_blank">https://lttng.org/man/3/lttng-ust/v2.8/</a><br>
> > > [2]: <a href="https://perfetto.dev/docs/instrumentation/track-events" rel="noreferrer noreferrer" target="_blank">https://perfetto.dev/docs/instrumentation/track-events</a><br>
> ><br>
> > <snip><br>
> ><br>
> > > I agree that in the current functionalities, it's not that hard to implement<br>
> > > a homemade C/python parser, and generate Perfetto code with jinja2.<br>
> > > However, we not only "limit" the functionalities of Perfetto with lttng's<br>
> > > definition, but also add another layer to be maintained.<br>
> > > It's true that having duplication of libcamera tracepoint definitions<br>
> > > requires more maintenance work when updating the libcamera<br>
> > > tracepoints, while the effort to maintain the parser and code generation<br>
> > > is also non-negligible.<br>
> > ><br>
> > > I also think that creating a new language from which we generate<br>
> > > tracepoints for both is an overkill though. It seems that we don't have<br>
> > > a perfect way to support both lttng and Perfetto...<br>
> > ><br>
> > > BTW, I tried lex and yacc to parse lttng macros, and tbh it's very painful<br>
> > > that it's very hard to use lex to recognize C/C++ type as a token... So<br>
> > > yeah if we end up deciding to take this route, a homemade parser from<br>
> > > scratch makes more sense to me.<br>
> > ><br>
> > > So let me list the approaches with pros and cons:<br>
> > > 1. Generate Perfetto code from lttng macros.<br>
> > >   Pros: Easy to update libcamera tracepoint macros.<br>
> > >   Cons: Add maintenance work with the additional parser and code<br>
> > > generator; hard to implement Perfetto features that lttng doesn't have.<br>
> ><br>
> > This makes me wonder, if Perfetto is a superset of the features of<br>
> > lttng, why not go the other way; use Perfetto tracepoints as the main<br>
> > authority and then generate lttng tracepoints from those.<br>
> ><br>
> > What are your thoughts?<br>
> <br>
> I don't think Perfetto MACROs is a superset of lttng MACROs. If we go<br>
> with this approach, there are some features dropped (like integer_hex<br>
> and enum, and the concept of TP_ARGS), and the code would be messy.<br>
> Take request_complete_buffer as the example:<br>
> <br>
> ```<br>
> # Perfetto<br>
> TRACE_EVENT("libcamera", "request_complete_buffer",<br>
>       "request_private_ptr", reinterpret_cast<uintptr_t>(req),<br>
>       "cookie", req->_o<libcamera::Request>()->cookie(),<br>
>       "status", req->_o<libcamera::Request>()->status(),<br>
>       "buffer_ptr", reinterpret_cast<uintptr_t>(buf),<br>
>       "buffer_status", buf->metadata().status);<br>
> ```<br>
> <br>
> It'd be how perfetto implements the macro. Originally lttng has only two<br>
> inputs: `libcamera::Request::internal *req` and<br>
> `libcamera::FrameBuffer *buf`. Unless we're going to do complicated<br>
> type diagnosis and simplification, we might end up with having five<br>
> inputs as well.</div></div></div></blockquote></div></div></blockquote></div></blockquote></div></blockquote></div></div></blockquote></div></div></blockquote><div> </div><div>I take this back. As we'll most likely have a self-defined</div><div>function that takes the two inputs with the correct C/C++</div><div>types, we might still be able to maintain the input size for</div><div>lttng macros.</div><div><br></div><div>BR,<br>Harvey<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote">Also, I don't know how to indicate the usage of<br>
> ctf_integer_hex (for `req` and `buf`) and ctf_enum (for status).<br>
> <br>
> I'd still prefer the 3rd or 4th approach.<br>
<br>
The 4th option, duplicating trace points in the libcamera sources, is<br>
the one I like the least. The 3rd option is also something I don't like<br>
much. It means that anyone adding trace points will need to do extra<br>
work to support two trace systems. Testing it locally will be hard, even<br>
for build testing. We could possibly handle the build testing with CI<br>
(see below), even if that will be way less convenient that doing local<br>
builds. Runtime testing is likely out of question.<br>
<br>
I'm not comfortable with the amount of extra work this will cause to<br>
everybody to support a Google-only trace system. I'm willing to find a<br>
compromise though, if Google could do the necessary work needed to<br>
package Perfetto in distributions, I could accept extra work on our side<br>
too.<br>
<br>
> > > 2. Creating a new language from which we generate both Perfetto<br>
> > > and lttng macros.<br>
> > >   Pros: Easy to update libcamera tracepoint macros.<br>
> > >   Cons: Probably an overkill; hard to cover all features from both<br>
> > > Perfetto and lttng.<br>
> > ><br>
> > > 3. As this patch implements: have duplicated libcamera tracepoint<br>
> > > definitions.<br>
> > >   Pros: Easy to add libcamera tracepoint macros to cover all features<br>
> > > from Perfetto & lttng.<br>
> > >   Cons: Developer needs to update both sides when the definition of<br>
> > > libcamera tracepoints changes; Unused macro definitions might be<br>
> > > adopted in both sides, if a feature is only available in one trace<br>
> > library.<br>
> > ><br>
> > > 4. Add another set of libcamera tracepoints for Perfetto, or just use<br>
> > > Perfetto macros directly in libcamera's source code.<br>
> > >   Pros: Two isolated trace stacks that don't influence each other. All<br>
> > > features can be implemented easily.<br>
> > >   Cons: Duplicated trace code in source code that might lead to<br>
> > > confusion; developers also need to update both macros when a<br>
> > > new trace is needed.<br>
> > ><br>
> > > I think approach 3rd and 4th are easier to maintain in the long<br>
> > > term. WDYT?<br>
> > ><br>
> > > Also, I'd like to know if you think Perfetto will be used in other linux<br>
> > > distributions than ChromeOS or Android.<br>
> ><br>
> > If Perfetto gets added to the package repositories in linux<br>
> > distributions then I think it would be used :)<br>
> ><br>
> > Not being able to sudo apt install perfetto is a pretty big blocker.<br>
><br>
> Yeah I understand, while Perfetto is self-contained and simple to build<br>
> in linux distros.<br>
<br>
Do you mean by running the tools/install-build-deps script that<br>
downloads toolchain binaries from google servers ? That doesn't really<br>
match the philosophy of Linux distributions.<br></div></div></div></blockquote><div><br></div><div>Yeah not accepting this makes sense I'm sympathetic to this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div class="gmail_quote">
<br>
> May we consider testing it on the gitlab CI, after we<br>
> somehow add the support?<br>
<br>
If we add support for it I certainly would like to see it being tested<br>
in CI, yes. After a quick look at the Perfetto build system, it looks<br>
like adding Perfetto to the CI docker containers may not be trivial.<br>
Someone will need to volunteer.<br>
<br>
> > > Chinglin, please help amend anything I missed as well :)<br>
<br>
-- <br>
Regards,<br>
<br>
Laurent Pinchart<br>
</div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>BR,</div>Harvey Yang</div></div></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "Perfetto-dev" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:perfetto-dev+unsubscribe@google.com" rel="noreferrer" target="_blank">perfetto-dev+unsubscribe@google.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/a/google.com/d/msgid/perfetto-dev/CAC%3DwSGWxc4W9nZOoieTMhG9h-Kh%2BwH%3D%3DiPfNwxqd0ybNntVFWQ%40mail.gmail.com?utm_medium=email&utm_source=footer" rel="noreferrer" target="_blank">https://groups.google.com/a/google.com/d/msgid/perfetto-dev/CAC%3DwSGWxc4W9nZOoieTMhG9h-Kh%2BwH%3D%3DiPfNwxqd0ybNntVFWQ%40mail.gmail.com</a>.<br>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>BR,</div>Harvey Yang</div></div></div>
</blockquote></div></div>
</blockquote></div></div>