Support of directory traces other than CTF

[bhufmann]

The trace detection algorithm checks recursively for CTF traces. If no CTF trace are found under the root directory, then use the root directory as trace directory. The trace server back-end will validate if this path points to a valid trace or not.

With this it's now possible to open traces that are directories other than CTF.

Note that only a single trace can be opened in the experiment and not set of traces, which is currently only supported with CTF traces.

Examples trace type: uftrace

Signed-off-by: Bernd Hufmann [email protected]

[MatthewKhouzam]

Thanks for the fix, instead, can we have the function isCtf renamed to isKnownDirTrace

and line 202 would be if (child[0] === 'metadata' || child[0] === 'info') {

That would allow us to recurse on uftraces too. I think it would allow CTF and uftrace to play well together. Maybe both changes are needed.

[MatthewKhouzam]

On second though, info just gave me some false positives, the name is not very unique. I don't know, Bernd, what do you think?

[yskelg]

Thank you @bhufmann @MatthewKhouzam for the great works!

[namhyung]

Thanks for working on this. For checking uftrace data directory, you can use "default.opts" file.

[bhufmann]

Thanks for working on this. For checking uftrace data directory, you can use "default.opts" file.

Thanks for the suggestion. This would be useful if we'd like to support experiments with multiple uftrace traces and/or a combination of CTF traces and uftraces. This is out-of-scope of this PR and should be handled separately.

[bhufmann]

On second though, info just gave me some false positives, the name is not very unique. I don't know, Bernd, what do you think?

files with name info are more common. I noticed that each git rebository has such a file underneath .git. Experiment support with multiple uftraces and/or combination of CTF traces and uftrace is out-of-scope of this PR and should be handled separately.