ftrace_log: Add override for tracefs location #126
Conversation
It's possible to mount tracefs in other locations - the Google Pixel 6, for example, mounts tracefs at /sys/kernel/tracing rather than the typical location inside debugfs at /sys/kernel/debug/tracing and disallows debugfs from being mounted when running any GKI kernel. This change allows configurations to select the location where rt-app will attempt to configure tracing when enabled. If it is not supplied, then the intended behaviour is that the existing default should be used. There should not be any impact on existing json files running on existing systems. Signed-off-by: "Chris Redpath" <[email protected]>
credp
force-pushed
the
tracefs_path_set
branch
3 times, most recently
from
c5ff4f0 to
282918a
Compare
|
@DouglasRaillard Here you go - it's tested on my VM but the P6 will be a bit longer as I am starting from scratch on it again. |
|
@credp it builds but there is a warning to fix: |
Ooh, thanks. I changed the ftrace_dir to use strdup instead of using a static string buffer and forgot to fix this bit up. Will repost |
If you don't provide a tracing location in the global config key section, rt-app usually looks in /sys/kernel/debug for the tracing folder. As part of this, switch the internals to use the full tracing path instead of relying upon adding /tracing/ to the path of files used. This patch allows rt-app to examine the content of /etc/mtab, and apply the following ordering: * If tracefs is mounted, use that location * If tracefs is not found anywhere, then look for debugfs - If we use debugfs, append "/tracing" to the path * If we find neither, just use /sys/kernel/debug/tracing Using the default means we couldn't find tracefs or debugfs mounted and so is likely to fail later if you are using ftrace, but should have no impact if you're not tracing. All of the path selection is overridden if you provide the config key. This should allow rt-app to work on any platform, at least from tracing POV. Signed-off-by: Chris Redpath <[email protected]>
| return tmp; | ||
| } | ||
|
|
||
| return strdup(DEFAULT_FTRACE_DIR); |
There was a problem hiding this comment.
do we really need to return a default path ? there is no chance that this can work, isn't ?
Should be better return null and escape early in the main thread
There was a problem hiding this comment.
If I return NULL here, it means that if the mtab code fails we cannot use ftrace unless we provide a path in the global section. That's probably OK, I don't mind that if you dont.
There was a problem hiding this comment.
I wondering if there is a usecase where mtab would fail but the default path could work
There was a problem hiding this comment.
I don't think so, and if that does happen you can always add ftracedir to your global options file to force it to a specific location. I'll push a new squashed rev up once I've tested it a bit.
It's possible to mount tracefs in other locations - the Google Pixel 6,
for example, mounts tracefs at /sys/kernel/tracing rather than the
typical location inside debugfs at /sys/kernel/debug/tracing and disallows
debugfs from being mounted when running any GKI kernel.
This change allows configurations to select the location where rt-app
will attempt to configure tracing when enabled. If it is not supplied,
then the intended behaviour is that the existing default should be used.
There should not be any impact on existing json files running on existing
systems.
Signed-off-by: "Chris Redpath" [email protected]