Add pictures made by Brendan Gregg under CC BY-SA 4.0 Deed license with common syseng/perf tools (#170)

[ia]

TL; DR: add useful pictures with overview of commonly known tools, for probable "fix" of this "issue". If some changes are required, just let me know. And excuse me in advance in case if this PR is not appropriate for some reason.

---

Hello. Unfortunately, I'm not familiar with (La)TeX so I can't add a full-featured slide(s) into this pull-request. But once I saw the update to the issue I decided to try & to contribute my little help on that.

These pictures made by Brendan Gregg under Creative Commons license so there is no any violation here. And I hope you don't take it as some kind of marketing nor "advertising" by me. I just thought that why we should do the work which already has been done by someone else already? Isn't that the whole point of Free & Open Source Software? ;)

DISCLAIMER (just in case): currently I'm not affiliated with any commercial company or any commercial project in any way.

---

P.S. Since we're here, I would like to thank everyone behind Bootlin. I'm a GNULinux user since 2004, GitHub user since 2008 but only recently I re-discover the beauty of finally contributing back at least something to the projects which I use all these years. Using this opportunity, I would like to say how much I thankful for your work:

• for your fast & reliable online Linux kernel code navigator which helps me a lot;
• for your online hosting of prebuilt toolchains of all "flavors" - there were moments when it was a life-saver for me right in the middle of the deadline on a couple of commercial embedded projects;
• for your awesome talks & workshops at Linux Foundation-related events (and for publishing them online);
• for your own Youtube channel with awesome talks!

Keep it up! Happy Hacking.

[Tropicao]

Hello @ia , thank you for your interest in contributing to our training materials ! Brendan Gregg's pictures are indeed very good to get a general overview of available tools for debugging, tracing and profiling.

Unfortunately, we can not integrate your submission as-is, for multiple reasons:

• as you mentioned, adding the images is not enough if they are not properly integrated into the materials (slides or labs instructions). We do not want to merely "store" new resources in the repository, those must be used in the materials.
• some of them are already present and introduced in the materials (bcc, bpftrace)
• some of the images are about new tools that are not mentioned at all in our slides, those needs to be properly introduced/explained if we want to add this kind of summary picture
• adding those pictures, even with proper introduction, does not really solve debugging: add a summary graph regrouping all tools by goals/usage #170 : the real issue is about giving hints to people about how to select the proper (level of) tool, giving the pros and cons of each tool on some defined criteria. Only adding summary images adding a ton of new different tools, even if those are sorted by kernel subsystem, may even confuse more training participants

[ia]

Thank you for taking time and providing the detailed feedback!

Unfortunately, we can not integrate your submission as-is, for multiple reasons:

I understand your points and I see their validity. And to be fully honest, what I was counting on indeed is that at least some of the images still could be put in the repo with one commit as-is first, but then someone else who is quick on its keyboard with TeX would just use them as starting point of adding more relevant full-featured slides/TeX(t) with more intro & description. :)

So... should I just close this PR now?

Another one suggestion though: we both could try to make it slowly but steady together transforming this PR into suitable one to merge, but it definitely will take some time on my side. In this case, the general plan could be something like that (in my humble opinion):

• first, someone [from Bootlin] would have to write down & provide the full list of tools which must be documented (in the manner as you described it in your issue report) since I'm not fully aware of this piece of information (i.e., what your trainees must be aware of in the first place);
• second, we decide to which degree every tool should be documented (brief one-line intro & usage VS detailed description with all parameters);
• third, documenting tools with plain text/simple tables first (so I could help on that);
• fourth, transforming text into TeX to get compile-able slides (once again, with huge help by someone familiar with TeX).

What do you think?

Oh, and I'm sorry if I'm sticking into not my business, but since this discussion not in corporate email but on public, my assumption for starting this was that that's the whole point of open documentation. ;) (great epic materials by the way!)

[Tropicao]

(sorry for the late reply)
Unfortunately the alternate plan you are suggesting to integrate your PR rely on us doing more work from our side to make it usable, and this work does not really go in the direction we are aiming for (fixing currently raised issues before widening the scope of introduced tools), so yes, closing the PR is likely the thing to do.