| Message ID | 20201209134203.428068-1-y.karadz@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Start KernelShark v2 transformation | expand |
On Wed, 9 Dec 2020 15:41:36 +0200 "Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote: > In this patch-set we are starting the introduction of the changes > in the C API of libkshark. The goal of this transformation is to > turn KernelShark into a general purpose toolkit for analysis of > tracing data that is no longer strongly coupled to the Ftrace/trace-cmd > data format. At the end of the transformation KernelShark will be able > to merge and simultaneously visualize data from different tracers, > recorded in different data formats. It will also significantly extend > the possibilities for user customization. > > This patch-set transforms the way KernelShark processes the raw tracing > data. Later, in a consecutive patch-sets we will introduce the changes > in the visualization instruments and in the KernelShark GUI itself. > > Steven, > I believe all patches in this set are ready to move upstream. > Thanks Yordan, I just realized that the current repo doesn't build against the latest libtracefs, because the library's location has moved. I noticed that the CMake files have it hard coded with: find_library(TRACEFS_LIBRARY NAMES tracefs/libtracefs.a find_library(TRACEFS_LIBRARY NAMES tracefs/libtracefs.so) Is there a way to make cmake use pkg-config? pkg-config --cflags --libs libtracefs Will give us the correct includes and libraries for building against libtracefs if installed. We'll want the same for libtraceevent and libtracecmd as well. -- Steve
On 2020-12-09 21:38:22 (-0500), Steven Rostedt wrote: > On Wed, 9 Dec 2020 15:41:36 +0200 > "Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote: > I just realized that the current repo doesn't build against the latest > libtracefs, because the library's location has moved. I noticed that > the CMake files have it hard coded with: > > find_library(TRACEFS_LIBRARY NAMES tracefs/libtracefs.a > find_library(TRACEFS_LIBRARY NAMES tracefs/libtracefs.so) > > Is there a way to make cmake use pkg-config? > > pkg-config --cflags --libs libtracefs > > Will give us the correct includes and libraries for building against > libtracefs if installed. > > We'll want the same for libtraceevent and libtracecmd as well. find_package() [1] is usually used for package discovery in cmake-land. If the NAMES argument is provided it overrides any provided package name. In more complex cases (of the package) it is better to have the package ship with a find_<PACKAGE>.cmake file that will be automatically used by cmake if it is installed in the system locations. To use pkg-config/pkgconf directly, it is possible to make use of the FindPkgConfig [2] module. Best, David P.S.: Out of context: Why is the cmake minimum requirement so low? To make use of useful features in cmake it needs to be at least 3.4, better higher even. [1] https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package [2] https://cmake.org/cmake/help/latest/module/FindPkgConfig.html
Hi David, On 10.12.20 г. 10:48 ч., David Runge wrote: > On 2020-12-09 21:38:22 (-0500), Steven Rostedt wrote: >> On Wed, 9 Dec 2020 15:41:36 +0200 >> "Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote: >> I just realized that the current repo doesn't build against the latest >> libtracefs, because the library's location has moved. I noticed that >> the CMake files have it hard coded with: >> >> find_library(TRACEFS_LIBRARY NAMES tracefs/libtracefs.a >> find_library(TRACEFS_LIBRARY NAMES tracefs/libtracefs.so) >> >> Is there a way to make cmake use pkg-config? >> >> pkg-config --cflags --libs libtracefs >> >> Will give us the correct includes and libraries for building against >> libtracefs if installed. >> >> We'll want the same for libtraceevent and libtracecmd as well. > > find_package() [1] is usually used for package discovery in cmake-land. > If the NAMES argument is provided it overrides any provided package > name. > In more complex cases (of the package) it is better to have the > package ship with a find_<PACKAGE>.cmake file that will be automatically > used by cmake if it is installed in the system locations. I agree. This is indeed the proper way to get CMake find the libtracefs automatically. And we should do the same for libtraceevent. > > To use pkg-config/pkgconf directly, it is possible to make use of > the FindPkgConfig [2] module. > > Best, > David > > P.S.: Out of context: Why is the cmake minimum requirement so low? To > make use of useful features in cmake it needs to be at least 3.4, better > higher even. > This is legacy and it has to be updated. Absolutely. Thanks a lot! Yordan > [1] https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package > [2] https://cmake.org/cmake/help/latest/module/FindPkgConfig.html >
On Thu, 10 Dec 2020 09:48:02 +0100 David Runge <dave@sleepmap.de> wrote: > On 2020-12-09 21:38:22 (-0500), Steven Rostedt wrote: > > On Wed, 9 Dec 2020 15:41:36 +0200 > > "Yordan Karadzhov (VMware)" <y.karadz@gmail.com> wrote: > > I just realized that the current repo doesn't build against the latest > > libtracefs, because the library's location has moved. I noticed that > > the CMake files have it hard coded with: > > > > find_library(TRACEFS_LIBRARY NAMES tracefs/libtracefs.a > > find_library(TRACEFS_LIBRARY NAMES tracefs/libtracefs.so) > > > > Is there a way to make cmake use pkg-config? > > > > pkg-config --cflags --libs libtracefs > > > > Will give us the correct includes and libraries for building against > > libtracefs if installed. > > > > We'll want the same for libtraceevent and libtracecmd as well. > > find_package() [1] is usually used for package discovery in cmake-land. > If the NAMES argument is provided it overrides any provided package > name. > In more complex cases (of the package) it is better to have the > package ship with a find_<PACKAGE>.cmake file that will be automatically > used by cmake if it is installed in the system locations. > > To use pkg-config/pkgconf directly, it is possible to make use of > the FindPkgConfig [2] module. > Yeah, that FindPkgConfig module looks like what we need. > Best, > David > > P.S.: Out of context: Why is the cmake minimum requirement so low? To > make use of useful features in cmake it needs to be at least 3.4, better > higher even. Note, I've never used cmake before Yordan introduced it to KernelShark. This question is better answered by Yordan. -- Steve > > [1] https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package > [2] https://cmake.org/cmake/help/latest/module/FindPkgConfig.html >
In this patch-set we are starting the introduction of the changes in the C API of libkshark. The goal of this transformation is to turn KernelShark into a general purpose toolkit for analysis of tracing data that is no longer strongly coupled to the Ftrace/trace-cmd data format. At the end of the transformation KernelShark will be able to merge and simultaneously visualize data from different tracers, recorded in different data formats. It will also significantly extend the possibilities for user customization. This patch-set transforms the way KernelShark processes the raw tracing data. Later, in a consecutive patch-sets we will introduce the changes in the visualization instruments and in the KernelShark GUI itself. Steven, I believe all patches in this set are ready to move upstream. Changes in v6: * The patches from the "OpenGL wrapper" patch-set (already reviewed by Steven) have been added here (patches 21-24). * Patches 25-27 are new, but these are only infrastructureal changes that have no functional effects on the API. Changes in v5: * Only minor modifications addressing issues pointed out by Steven in his reviews of v4. Changes in v4: * The integer data format identifier is replaced with a string value that gets registered by the readout plugin. * Plus several small modifications addressing the issues pointed out by Steven. Changes in v3. This version contains number of small modifications addressing the issues pointed out by Steven in his review. However, it also contains the following major changes: * The session context (kshark_context) holds a pointer to unspecified data processing interface (void *interface). This will allow to easily introduce new versions of this interface in the future, while keeping the interface that we have now for backward compatibility. The necessary type checking when using the interface made the helper functions wrapping the corresponding methods of the interface relatively complicated, so the implementations have been moved from the header to the source file. * A more sophisticated management of the Data stream descriptors that can handle the case when Data streams are constantly added and removed has been implemented. The design for this change was suggested by Steven in his review. Changes in v2: * Tried to address review comments for "kernel-shark: Introduce libkshark-hash" * The huge patch "kernel-shark: Integrate the stream definitions with the C API" in the previous version is now split into 8 smaller patches. The last of these 8 new patches (kernel-shark: Complete the stream integration) is still a bit entangled. I can try to further break this patch in future versions of the patch-set, if this is needed. Yordan Karadzhov (1): kernel-shark: Add "github Actions" workflow Yordan Karadzhov (VMware) (26): kernel-shark: Use only signed types in kshark_entry kernel-shark: Add stream_id to kshark_entry kernel-shark: Introduce libkshark-hash kernel-shark: Introduce Data streams kernel-shark: Rename static methods in libkshark kernel-shark: Add basic methods for Data streams kernel-shark: Housekeeping before implementing stream interface kernel-shark: Add stream interface for trace-cmd data kernel-shark: Start introducing KernelShark 2.0 kernel-shark: Start using data streams kernel-shark: Remove dead code kernel-shark: Redesign the plugin interface kernel-shark: Complete the stream integration kernel-shark: Provide merging of multiple data streams kernel-shark: Integrate the stream definitions with data model kernel-shark: Use only signed types for model defs kernel-shark: Add ksmodel_get_bin() kernel-shark: Protect ksmodel_set_in_range_bining() kernel-shark: Add methods for time calibration kernel-shark: Integrate streams with libkshark-configio kernel-shark: Add support for drawing text kernel-shark: Make GLUT optional dependency kernel-shark: Add ksplot_draw_polyline() kernel-shark: Optimize ksplot_draw_polygon() kernel-shark: Do not use the ARRAY_SIZE macro kernel-shark: Add basic infrastructure for testing .github/workflows/main.yml | 51 + CMakeLists.txt | 13 +- Documentation/doxygen/dox_config | 1 + build/cmake_clean.sh | 4 + build/deff.h.cmake | 15 +- examples/CMakeLists.txt | 34 +- examples/configio.c | 20 +- examples/datafilter.c | 67 +- examples/datahisto.c | 38 +- examples/dataload.c | 28 +- examples/multibufferload.c | 53 + src/CMakeLists.txt | 12 +- src/libkshark-collection.c | 121 +- src/libkshark-configio.c | 1208 +++++-- src/libkshark-hash.c | 239 ++ src/libkshark-model.c | 154 +- src/libkshark-model.h | 55 +- src/libkshark-plot.c | 315 +- src/libkshark-plot.h | 73 + src/libkshark-plugin.c | 658 +++- src/libkshark-plugin.h | 294 +- src/libkshark-tepdata.c | 1914 ++++++++++++ src/libkshark-tepdata.h | 112 + src/libkshark.c | 2619 +++++++++------- src/libkshark.h | 704 ++++- src/stb_truetype.h | 5011 ++++++++++++++++++++++++++++++ tests/CMakeLists.txt | 14 + tests/libkshark-tests.cpp | 48 + 28 files changed, 12018 insertions(+), 1857 deletions(-) create mode 100644 .github/workflows/main.yml create mode 100644 examples/multibufferload.c create mode 100644 src/libkshark-hash.c create mode 100644 src/libkshark-tepdata.c create mode 100644 src/libkshark-tepdata.h create mode 100644 src/stb_truetype.h create mode 100644 tests/CMakeLists.txt create mode 100644 tests/libkshark-tests.cpp