[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d3433041-33e3-f013-7631-b162d6f35af6@kernel.org>
Date: Thu, 25 Nov 2021 14:37:14 +0100
From: Daniel Bristot de Oliveira <bristot@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Tao Zhou <tao.zhou@...ux.dev>, Ingo Molnar <mingo@...hat.com>,
Tom Zanussi <zanussi@...nel.org>,
Masami Hiramatsu <mhiramat@...nel.org>,
Juri Lelli <juri.lelli@...hat.com>,
Clark Williams <williams@...hat.com>,
John Kacur <jkacur@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-rt-users@...r.kernel.org, linux-trace-devel@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V7 01/14] rtla: Real-Time Linux Analysis tool
On 11/24/21 22:28, Steven Rostedt wrote:
> On Fri, 29 Oct 2021 21:26:04 +0200
> Daniel Bristot de Oliveira <bristot@...nel.org> wrote:
>
>> The rtla is a meta-tool that includes a set of commands that aims
>> to analyze the real-time properties of Linux. But instead of testing
>> Linux as a black box, rtla leverages kernel tracing capabilities to
>> provide precise information about the properties and root causes of
>> unexpected results.
>>
>> rtla --help works and provide information about the available options.
>>
>> This is just the "main" and the Makefile, no function yet.
>>
>> Cc: Steven Rostedt <rostedt@...dmis.org>
>> Cc: Ingo Molnar <mingo@...hat.com>
>> Cc: Tom Zanussi <zanussi@...nel.org>
>> Cc: Masami Hiramatsu <mhiramat@...nel.org>
>> Cc: Juri Lelli <juri.lelli@...hat.com>
>> Cc: Clark Williams <williams@...hat.com>
>> Cc: John Kacur <jkacur@...hat.com>
>> Cc: Peter Zijlstra <peterz@...radead.org>
>> Cc: Thomas Gleixner <tglx@...utronix.de>
>> Cc: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
>> Cc: Daniel Bristot de Oliveira <bristot@...nel.org>
>> Cc: linux-rt-users@...r.kernel.org
>> Cc: linux-trace-devel@...r.kernel.org
>> Cc: linux-kernel@...r.kernel.org
>> Signed-off-by: Daniel Bristot de Oliveira <bristot@...nel.org>
>> ---
>> tools/tracing/rtla/Makefile | 76 +++++++++++++++++++++++++++++++++++
>> tools/tracing/rtla/src/rtla.c | 72 +++++++++++++++++++++++++++++++++
>> 2 files changed, 148 insertions(+)
>> create mode 100644 tools/tracing/rtla/Makefile
>> create mode 100644 tools/tracing/rtla/src/rtla.c
>>
>> diff --git a/tools/tracing/rtla/Makefile b/tools/tracing/rtla/Makefile
>> new file mode 100644
>> index 000000000000..33f154f86519
>> --- /dev/null
>> +++ b/tools/tracing/rtla/Makefile
>> @@ -0,0 +1,76 @@
>> +NAME := rtla
>> +VERSION := 0.3
>> +
>> +# From libtracefs:
>> +# Makefiles suck: This macro sets a default value of $(2) for the
>> +# variable named by $(1), unless the variable has been set by
>> +# environment or command line. This is necessary for CC and AR
>> +# because make sets default values, so the simpler ?= approach
>> +# won't work as expected.
>> +define allow-override
>> + $(if $(or $(findstring environment,$(origin $(1))),\
>> + $(findstring command line,$(origin $(1)))),,\
>> + $(eval $(1) = $(2)))
>> +endef
>> +
>> +# Allow setting CC and AR, or setting CROSS_COMPILE as a prefix.
>> +$(call allow-override,CC,$(CROSS_COMPILE)gcc)
>> +$(call allow-override,AR,$(CROSS_COMPILE)ar)
>> +$(call allow-override,STRIP,$(CROSS_COMPILE)strip)
>> +$(call allow-override,PKG_CONFIG,pkg-config)
>> +$(call allow-override,LD_SO_CONF_PATH,/etc/ld.so.conf.d/)
>> +$(call allow-override,LDCONFIG,ldconfig)
>> +
>> +INSTALL = install
>> +FOPTS := -flto=auto -ffat-lto-objects -fexceptions -fstack-protector-strong \
>> + -fasynchronous-unwind-tables -fstack-clash-protection
>> +WOPTS := -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -Wno-maybe-uninitialized
>> +
>> +TRACEFS_HEADERS := $$($(PKG_CONFIG) --cflags libtracefs)
>> +
>> +CFLAGS := -O -g -DVERSION=\"$(VERSION)\" $(FOPTS) $(MOPTS) $(WOPTS) $(TRACEFS_HEADERS)
>> +LDFLAGS := -ggdb
>> +LIBS := -ltracefs -ltraceevent -lprocps
>
> For the -ltracefs and -ltracevent, you could use:
>
> $$($PKG_CONFIG) --libs libtracefs)
>
> which would be more robust.
Will use!
-- Daniel
> -- Steve
>
Powered by blists - more mailing lists